Управління Web-сервісами

1. , А тому досить складно контролювати і вимірювати Web-сервіси, управляти їх готовністю і продуктивністю.
2. Управління розподіленими сервісами
3. Вимоги до якості
4. Концептуальна архітектура управління
5. Платформи розподіленого управління
6. Управління Web-сервісами
7. Методи управління сервісами
8. Управління інфраструктурними сервісами
9. Управління сервісами та додатками
10. література
11. Стандарт управління Web-сервісами

01.06.2006 Майкл Папазоглоу, Віллем-Ян ван ден Хьювел

, А тому досить складно контролювати і вимірювати Web-сервіси, управляти їх готовністю і продуктивністю.

Розглянемо зв'язку між управлінням Web-сервісами і традиційними розподіленими системами, а також підходи до управління Web-сервісами і їх основотвірний архітектурні концепції.

Сьогодні Web-сервіси - найпопулярніша парадигма розподілених обчислень. Беручи на озброєння сервіс-орієнтовані архітектури (service-oriented architecture, SOA) на базі Web-сервісів, підприємства можуть гнучко вирішувати внутрішньо-і міжкорпоративні проблеми інтеграції. Web-сервіси починають грати все більш важливу роль в житті підприємств, і контроль над ними стає нагальною потребою. Направляючи розвиток Web-сервісів, можна отримувати чітке уявлення про їхню роботу, обгрунтовано приймати управлінські рішення і здійснювати дії, що управляють для адаптації поведінки додатків на їх базі. Для всього цього потрібні розподілені засоби управління Web-сервісами.

При управлінні розподіленими системами набори інструментів і утиліти контролюють їх дії, що полегшує прийняття управлінських рішень і внесення змін в поведінку систем. За традицією основна увага досі приділялося управлінню послідовними рівнями нових технологій, які вводилися в експлуатацію в розподілених середовищах. Однак такі методи не відповідають корпоративним вимогам, оскільки не відповідають бізнес-функцій. Крім того, багато інфраструктури системного управління не забезпечують контролю над угодами про рівень обслуговування (service level agreement, SLA) або отримання від додатків на базі Web-сервісів інформації про обслуговування, необхідної для усунення помилок.

Експлуатуючи рішення на базі SOA, ІТ-адміністратори повинні безперервно аналізувати моделі використання сервісів, критерії та метрики SLA, дані про відмови. Без такої інформації досить важко розуміти причини проблем з продуктивністю і стабільністю додатків SOA. Зокрема, підприємства повинні контролювати і вимірювати рівні обслуговування розподілених і консолідованих процесів. Спостерігаючи за бізнес-процесами, ІТ-адміністратори можуть виявляти сприятливі можливості і діагностувати проблеми в міру їх виникнення. Завдяки цьому Web-сервіси, що підтримують конкретну бізнес-завдання, виконуються відповідно до вимог SLA.

Постачальники засобів управління пропонують вимірювальні інструменти тільки для кінцевих точок і вузлів-посередників SOAP або серверів UDDI. Що Забезпечує даними інструментами уявлення про використання Web-сервісів додатками страждає неповнотою: йому не вистачає життєво важливої ​​інформації про стан і характеристики Web-сервісів. Для отримання таких відомостей Web-сервіси повинні стати вимірними і більш керованими. Цього можна досягти тільки шляхом стандартизації, яка забезпечить наскрізну керованість всіх частин долгоживущей багатокрокової транзакції, що охоплює кілька додатків, підприємств і дійових осіб.

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

Управління розподіленими сервісами

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

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

Використання Web-сервісів для організації доступу до успадкованих додатків і їх розширення дає підприємствам явні технологічні переваги. Об'єднання сервісів в дискретні логічні компоненти, безпосередньо ув'язані з бізнес-функціями, допомагає отримати ще більш істотні плюси. Компанії можуть «оркеструвати» такі сервіси в багатьох конфігураціях для підтримки декількох бізнес-процесів. Оркестрована реалізація сервісів формує логічну мережу послуг, накладену поверх інфраструктури (в тому числі програмного середовища, серверів, успадкованих додатків, внутрішніх систем) і фізичної мережі зв'язку. У міру розростання такої мережі Web-сервісів її робота і продуктивність стають життєво важливими для ключових бізнес-операцій.

Вимоги до якості

Постачальник і покупець повинні домовитися про особливості сервісу. У додатках, які об'єднують географічно розподілені Web-сервіси, такий договір становить суть корпоративної угоди SLA. Мета полягає в тому, щоб поліпшити фактичну якість послуг (quality of experience, QoE) для внутрішніх або зовнішніх клієнтів. QoE створює єдину основу для вимірювання якості продукту або послуги, в тому числі продуктивності, перед- і післяпродажного обслуговування, ступеня задоволеності клієнта. Постачальник часто повинен укласти і контролювати виконання кілька внутрішніх (для бізнесу або кінцевих користувачів) або зовнішніх (для постачальників послуг, партнерів, аутсорсеров і т.д.) угод SLA. Взагалі кажучи, бізнес-процес передбачає кілька угод SLA, керуючих взаємопов'язаними послугами в інтересах кінцевого користувача. Для кожного рівня SLA одну зі сторін можна вважати постачальником, а іншу - споживачем.

Забезпечення якісного сервіс-орієнтованого управління вимагає вимірювання ключових показників ефективності (Key Performance Indicator, KPI) додатків і послуг. Постачальник послуг може розглянути загальні KPI перед їх застосуванням до конкретних додатків. До загальних KPI бізнес-додатків відносяться доступність і продуктивність сервісу, час відгуку і швидкість виконання транзакцій, час простою і безпеку. Постачальник повинен знати, чи відповідають його послуги встановленими показниками KPI, і бити на сполох у разі «накладок». Йому необхідно встановити для сервісу цільові показники KPI, навчитися їх вимірювати і аналізувати, а також звітувати про KPI, що відрізняються від цільових.

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

Концептуальна архітектура управління

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

Консоль управління відображає інформацію через інтерфейс, що дозволяє адміністраторам контролювати ресурси і змінювати їх поведінку. Інтерфейс управління використовує такі механізми, як журнали, події, команди, інтерфейси API і файли конфігурації [1]. Як показано в лівій нижній частині рис. 1, інтерфейс також застосовує метадані про властивості ресурсу:

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

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

Платформи розподіленого управління

Широко застосовуються кілька стандартних платформ розподіленого управління. Серед найбільш відомих варто згадати SNMP (Simple Network Management Protocol - «простий протокол управління мережею», www.ietf.org/rfc/rfc1157.txt ), CIM (Common Information Model - «загальна інформаційна модель», www.dmtf.org/standards/cim/ ), WBEM (Web-Based Enterprise Management - «технологія корпоративного управління на базі Web», www.dmtf.org/standards/wbem/ ) І OMI (Open Management Interface - «відкритий інтерфейс управління», www.openview.hp.com/ downloads / try_omi_0001.html ).

SNMP, запропонований IETF, - це протокол прикладного рівня, який полегшує обмін керуючою інформацією між мережевими пристроями [2]. Елементами мережі SNMP є пристрої (такі, як хости, шлюзи і термінальні сервери), забезпечені агентами. Останні виконують функції, запитувані станціями управління мережею. Платформа SNMP дозволяє мережевим адміністраторам управляти пропускною спроможністю мережі, знаходити і усувати несправності, планувати нарощування мережі. Фактично SNMP є галузевим стандартом мережевого управління.

Модель CIM, розроблена робочою групою з управління розподіленими системами DMTF (Distributed Management Task Force), описує всі керовані елементи підприємства, в тому числі системи, мережі та додатки. CIM не залежить від реалізації і дозволяє керуючим додатків збирати необхідні дані з різних джерел. Група розробила також WBEM - набір стандартів управління і технологій Internet, націлених на уніфікацію управління корпоративною обчислювальним середовищем. Спираючись на WBEM, можна побудувати інтегрований набір інструментів на базі стандартів, які використовують переваги, що розвиваються Web-технологій.

Інтерфейс OMI, спільно розроблений компаніями Hewlett-Packard і webMethods [3], надає постачальникам систем управління та іншим зацікавленим сторонам легкий відкритий доступ до управління ресурсами, пов'язаними з платформою інтеграції і до мають до нього відношення бізнес-процесів. OMI дозволяє керуючим інфраструктур за допомогою програмного інтерфейсу отримати доступ до управління інтегрованої платформою бізнес-процесів. Через цей інтерфейс користувачі можуть управляти набором об'єктів OMI, що представляють доступні ресурси.

Управління Web-сервісами

Коли традиційні централізовані керуючі додатки переходять до розподілених динамічних архитектурам SOA, вони можуть більш гнучко виконувати основні функції управління. В рамках SOA платформа управління Web-сервісами WSMF (Web Services Management Framework) забезпечує підтримку виявлення, аналізу, захисту і звернення до ресурсів, а також виконання функцій управління і підтримку інфраструктурних керуючих сервісів і наборів інструментів. Ті ж технології, що визначають бізнес-процеси і високорівневі процеси управління ІТ, тепер можуть узгоджуватися з технологіями менеджерів ресурсів, інфраструктурних сервісів і управління ресурсами.

Методи управління сервісами

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

Управляти інфраструктурою Web-сервісів вдається не завжди, але організації можуть контролювати потік повідомлень SOAP, якими обмінюються програми. Дійсно, аналіз трафіку і зміна повідомлень SOAP (які можуть бути перехоплені в багатьох точках мережі додатків, пов'язаних через Web-сервіси) є основними принципами управління Web-сервісами. Контейнери для сервісів полегшують побудову середовища потоку повідомлень типу «запит-відповідь». Подібно контейнерів J2EE, контейнери для Web-сервісів на увазі фізичне прояв кінцевої точки абстрактного сервісу і забезпечують реалізацію сервісного інтерфейсу.

ІТ-адміністратори можуть вводити засоби управління сервісами в конвеєр SOAP, використовуючи агентів або посередників. Управління сервісами за допомогою агентів відповідає контейнерному стилю управління. В даному випадку «рідний» для платформи контейнер Web-сервісу має можливості управління. З архітектурної точки зору вигода цієї моделі полягає в наступному. Агент здатний використовувати переваги конфігурації конкретної інфраструктури контейнера бізнес-додатків (сервера додатків), який адміністратори можуть кластеризувати і захищати для досягнення необхідного рівня обслуговування.

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

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

Управління інфраструктурними сервісами

Для управління послугами платформа WSMF використовує властивості керованості архітектурних ресурсів. Вони визначають стандартні схеми, метадані та інтерфейси мови опису Web-сервісів WSDL (Web Services Description Language), що описують поведінку ресурсів, за допомогою якого останні забезпечують доступ до інформації про керованість [4]. Як правило, ресурси реалізують тільки застосовні, а не всі свої стандартні властивості керованості, які включають в себе експлуатаційний статус, метрику і відносини.

Властивості керованості реалізуються через інформаційну модель керованості, яка представляє керованість ресурсу і супутню інформацію, таку як стан, конфігурація і відносини [5]. Платформа управління сервісами використовує інформацію з цієї моделі, яка може, наприклад, вказувати, що заголовок повідомлення SOAP містить цифрове посвідчення особи клієнта. WSMF витягує ці відомості і задіє для ідентифікації клієнта (наприклад, під час підрахунку повідомлень SOAP певного клієнта для конкретного Web-сервісу).

WSMF застосовує інфраструктурні сервіси управління для визначення стандартних інтерфейсів до загальнодоступних функцій інфраструктури [4]. До числа таких сервісів відносяться вимір, посередницькі функції при обробці метрик і подій, моніторинг, сканування системи, реалізація політик і мости між моделями. Стандартні інтерфейси управління дозволяють виконувати утиліти, процесів і програм більш високого рівня, такі як управління готовністю і продуктивністю, оптимізація, планування завантаження, формування рахунків, управління конфігурацією, захист ресурсів, виявлення проблем, бізнес-аналіз.

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

Web-сервіс є керованих, если его Властивості керованості Доступні через Стандартні інтерфейси управління, подібні функціональнім інтерфейсів [5]. Інтерфейси управління відрізняються лишь тім, что ма ють семантику, пов'язану з керування, и їх вікорістовує система управління Web-сервісамі, а не клієнт. на Мал. 3 показані інтерфейси управління Web-сервісу, доступні для платформи WSMF. Документ WSDL описує інтерфейси управління і кінцеві точки, яким WSMF може посилати повідомлення, пов'язані з управлінням. WSMF логічно грає роль сполучної ланки між постачальниками і споживачами Web-сервісів.

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

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

Управління сервісами та додатками

На додаток до традиційних засобів розробки прикладних сервісів для ефективного управління системами і додатками архітектура SOA на базі Web-сервісів вимагає двох ключових функцій:

• єдиної платформи управління для гетерогенного набору складових систем;
• підтримки комплексних, межкомпонентних сценаріїв управління, таких як дотримання угод SLA і динамічне надання ресурсів.

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

У цій архітектурі управління сервісами на увазі підбір сервісів, що взаємодіють один з одним під час передачі даних або координації певних операцій, що полегшує надання однієї або декількох бізнес-послуг. Замість того щоб наказувати конкретний протокол управління або технологію вимірювань, архітектура забезпечує роботу з протоколом SOAP, розширеннями JMX (Java Management Extensions), технологією WBEM і іншими (в тому числі майбутніми) технологіями і стандартами.

На рис. 4 до керованим ресурсів належать фізичні та логічні програмні і апаратні засоби. Ці ресурси публікують свої властивості керованості у вигляді Web-сервісів, які реалізують різні інтерфейси, наприклад певні в специфікації розподіленого управління Web-сервісами WSDM (Web Services Distributed Management). Інтерфейс управління ресурсом описується документом WSDL, схемою властивостей ресурсу, документами метаданих і, можливо, набором політик, пов'язаних з управлінням.

У процесі управління або в бізнес-процесі менеджери ресурсів можуть безпосередньо звертатися до ресурсів. Як показано на рис. 4, на двох взаємодіючих підприємствах бізнес-процес заснований на базових сервісах, таких як перевірка кредитоспроможності, відвантаження, обробка замовлення і управління складськими запасами. Керуючі додатки архітектури контролюють ресурси через їх інтерфейси або сервіси інфраструктури [4]. Ці менеджери забезпечують ряд функцій, в тому числі простий моніторинг, контроль, автономну настройку і відновлення, управління якістю, наскрізне управління бізнес-процесами, надання системних ресурсів і послуг на основі політик. Зазвичай вони підтримують інтерфейси і контент для консолей управління і відображають інформацію, пов'язану з керуванням. Менеджери взаємодіють з ресурсами і сервісами інфраструктури, застосовуючи інтерфейси Web-сервісів. Крім того, менеджери сервісів використовують мову WS-BPEL (Web Services Business Process Execution Language) для опису і виконання процесів управління, які забезпечують виконання заданих сценарієм функцій управління.

Рішення на базі SOA, призначені для розробки додатків і управління ними, заохочують застосування методів множинного зв'язування, а також такі загальнодоступні сервіси управління:

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

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

література

1. An Architectural Blueprint for Autonomic Computing. White paper, IBM, Oct. 2004; www-3.ibm.com/autonomic/ pdfs / AC wpFinal.pdf .
2. JD Case et al., Introduction to Version 3 of the Internet-Standard Network Management Framework, IETF RFC 2570. Apr. 1999; www.rfc-editor.org/rfc/rfc2570.txt .
3. G. Bullen et al., Open Management Interface Specification, v. 1.0, revision 1, Organization for the Advancement of Structured Information Standards. 2001; www1.webmethods.com/PDF/OMI_Spec.pdf .
4. H. Kreger et al., Management Using Web Services: A Proposed Architecture and Roadmap, tech report, IBM, Hewlitt-Packard and Computer Assoc. June 2005; www-128.ibm.com/developerworks/library/ specification / ws-mroadmap .
5. M. Potts, I. Sedukhin, H. Kreger, Web Services Manageability - Concepts (WS-Manageability), tech. report, IBM, Computer Assoc. and Talking Blocks. Sept. 2003; www3.ca.com/Files/SupportingPieces/ web_service_manageability_concepts.pdf .
6. W. Vambenepe, ed. Web Services Distributed Management: Management Using Web Services (MUWS 1.0) Part 1 and 2, Organization for the Advancement of Structured Information Standards. Mar. 2005; www.oasis-open.org/committees/download.php/11819/ wsdm-muws-part1-1.0.pdf .

Майкл Папазоглоу ( [email protected] ) - професор Університету Тілбург (Голландія). У сферу його наукових інтересів входять розподілені системи, сервіс-орієнтовані архітектури та Web-сервіси, інтеграція корпоративних додатків, технології та програми електронного бізнесу. Віллем-Ян ван ден Хьювел ( [email protected] ) - доцент Університету Тілбург. До його науковим інтересам відносяться сервіс-орієнтовані архітектури, еволюція систем і ув'язка нових корпоративних інформаційних систем з успадкованими.

Стандарт управління Web-сервісами

Узгоджене наскрізне управління Web-сервісами неможливо без розробки загальногалузевих стандартів. З цією метою організація OASIS (Organization for the Advancement of Structured Information Standards) активно розвиває специфікацію розподіленого управління Web-сервісами WSDM (Web Services Distributed Management; www.oasis-open.org ). Вона визначає протокол обміну керуючою інформацією через Web-сервіси. При вирішенні проблем управління розподіленими системами WSDM має на увазі два завдання: управління з використанням Web-сервісів (management using Web services, MUWS) і управління Web-сервісами (management of Web services, MOWS).

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

MOWS визначає вимоги до керуючих Web-сервісів. Відповідно до специфікації WSDM, Web-сервіси є основою розподілених обчислень, інтероперабельності, слабкого зв'язування і незалежності від реалізації. Специфікація MOWS базується на концепціях і визначеннях MUWS. Як і в MUWS, при визначенні моделі управління Web-сервісами в MOWS простежується прагнення залишатися в рамках існуючих модельних структур, а не заново винаходити узагальнену об'єктну модель керованих ресурсів.

Michael Papazoglou, Willem-Jan van den Heuvel, Web Services Management: A Survey, IEEE Internet Computing, Nov / Dec 2005. IEEE Computer Society, 2005, All rights reserved. Reprinted with permission.