Торік концепція сервісно-орієнтованої архітектури (Service-Oriented Architecture, SOA) стала об'єктом пильної уваги з боку директорів IT-служб. Понад половину IT-керівників, що взяли участь у недавньому опитуванні Computerworld й CIO Magazine, уже інвестують у розгортання SOA або мають намір реалізувати її для інтеграції своїх додатків. Крім того, SOA дозволить компаніям надавати сервіси безпосередньо своїм клієнтам. Основною причиною настільки сильного інтересу до SOA-архітектури стало прагнення компаній домогтися більшої гнучкості бізнесу й зниження витрат на інтеграцію вже використовуваних ними додатків. Однак більшість учасників опитування думають, що деякі інструментальні засоби й протоколи, на які опирається SOA, вимагають серйозної доробки.
За словами IT-керівників, після того як у компанії буде реалізована сервісно-орієнтована архітектура, вони мають намір використовувати її або для інтеграції додатків (44%), або для надання сервісів прямо своїм клієнтам або користувачам (28%), або для зв'язку із зовнішніми додатками, наданими партнерами (21%). Однак 53% респондентів планують застосовувати SOA для рішення всіх перерахованих вище завдань.
Приблизно дві третини респондентів проводять навчання співробітників компанії, для того щоб мати у своєму розпорядженні фахівців, необхідних для реалізації сервісно-орієнтованої архітектури, і майже половина (45%) мають намір звернутися до консультантів. Близько 41% учасників опитування заявили, що в їхній компанії є співробітники, що пройшли відповідне навчання. Майже 19% учасників опитування мають намір передати основну частину роботи на аутсорсінг. (Допускалося кілька варіантів відповідей.) На питання про те, яким образом вони мають намір одержати у своє розпорядження фахівців, необхідних для впровадження рішень на базі SOA, майже 40% керівників IT-служб відповіли, що планують навчати своїх співробітників.
Самими складними завданнями при розгортанні сервісно-орієнтованих архітектур IT-керівники, що беруть участь в опитуванні, уважають наступні: перехід на архітектуру й методологію SOA при одночасному задоволенні існуючих вимог бізнесу (63%); необхідність модернізації інфраструктури розраховуючи на підтримку SOA (56%); зміна методології, використовуваної розроблювачами з урахуванням особливостей SOA (47%). При виборі продуктів 62% IT-керівники назвали підтримку основних протоколів і стандартів SOA дуже важливою, а 36% заявили, що вона важлива до певного ступеня.
Для 77% респондентів головною причиною реалізації проектів, заснованих на ідеях SOA, стало прагнення підвищити гнучкість функціонування підприємства. Другим по важливості назване зниження витрат (61%). Приблизно половина опитаних (49%) указали як причина зниження витрат при впровадженні нових додатків, а 47% учасників опитування відзначили скорочення часу, необхідного на розробку нових додатків.

При згадуванні абревіатури SOA (Service-Oriented Architecture) більшість IT-спеціалістів перших справ згадують Web-сервіси й протокол HTTP, хоча цей термін позначає набагато ширше поняття. Архітектура SOA зовсім не залежна від мов програмування, платформ або протокольних специфікацій, за допомогою яких сервіси розробляються, а також від того, де й за допомогою чого вони розгорнуті. Практично архітектура SOA вимагає наявності не тільки сервісов, але й засобів, за допомогою яких ці сервіси можуть бути виявлені й підключені незалежно від основної інфраструктури. SOA - це не продукт або специфікація, тому ви не можете просто піти й купити “коробку з SOA”. Ви повинні настроїтися на ретельне вибудовування даної архітектури, що складається з безлічі компонентів, таких, як сервери додатків, що зв’язують ПО, репозитарій і навіть спеціалізовані пакети централізованого керування SOA.
Строго говорячи, SOA не можна відносити ні до нової реалізації CORBA, ні до обновленої архітектури RMI (Remote Method Invocation). Ключовий компонент SOA - сервіс. Сервіси тут є бізнес-функціями, призначеними для забезпечення погодженої роботи великих, що складаються з безлічі частин додатків. По суті, це будівельні блоки для відбиття бізнес-логіки в розроблювальних додатках. А кінцевим місцем, де сервіси “живуть”, є сервер додатків, будь то WebLogic від BEA Systems, WebSphere від IBM, Application Server від Oracle або Java AS від Sun Microsystems.

Зрозумілі функції

Функції, або операції, в SOAP (Simple Object Access Protocol) повинні бути інтуїтивно зрозумілими й відповідати своїм назвам - наприклад, submitPurchaseOrder (“підтвердити замовлення на покупку”) або validateCustomerAccounts (“перевірити особовий рахунок замовника”). На відміну від звичайних додатків сервіс в архітектурі SOA призначається для використання всім реалізованим бізнесам-функціям. У той час як звичайні корпоративні додатки містять у собі схожі фрагменти бізнесу-логіки або навіть дублюють окремі об'єкти - наприклад, об'єкт клієнтського замовлення, - в архітектурі SOA вам потрібно запустити лише єдиний екземпляр такої бізнес-функції. Таким чином, ви можете повторно використати функціональність у середовищі із множинними додатками й швидко коректувати бізнес-логіку, для того щоб мати можливість пристосовуватися до мінливих умов ринку. У цьому й складається головне достоїнство SOA.
Зі зміною єдиного екземпляра бізнес-функції в SOA автоматично вносяться корективи й в усі додатки, що опираються на цю функцію. Так що, наприклад, будь-які зміни в правилах ціноутворення або політики знижок застосовуються у всіх додатках. Аналогічно будь-які зміни в підтримуючій інфраструктурі залишаються прозорими для всіх додатків, що використовують сервіси. Наприклад, якщо ви переходите з однієї версії бази даних на іншу, то будуть модифіковані лише пов'язані з нею сервіси, оскільки додатки в архітектурі SOA працюють із усіма інфраструктурними додатками тільки за допомогою сервісів. У недавньому минулому зміни в сполучному ПО або в базі даних змушували переробляти всю систему, включаючи клієнтські настільні додатки.
Одне з важливих переваг архітектури SOA - її надійність, особливо якщо мова заходить про її реалізації на базі Web-сервісів і специфікації SOAP, що найбільше часто використовують протокол HTTP. Справа в тому, що споконвічно HTTP не планувався для цілей гарантованої доставки, тому сам по собі він не забезпечує надійного виконання критично важливих транзакцій. Для рішення цієї проблеми були створені два нових конкуруючих стандарта – WS-RM (Web Services Reliable Messaging) і WS-R (Web Services Reliability), але сучасні реалізації SOA для забезпечення гарантованої доставки використовують більш традиційні методи, - наприклад, ESB (Enterprise Service Bus).
Сполучне ПО ESB може слугувати опорою вашої архітектури SOA, забезпечуючи гарантовану доставку повідомлень, обробку виняткових ситуацій і використання всіх можливостей моделі “публікація-підписка”. Воно працює так само, як і традиційне сполучне ПО обміну повідомленнями, таке, як MQ Series фірми IBM, EMS фірми Tibco або JMS (Java Message Service), що виконує маршрутизацію повідомлень із їхнім проміжним зберіганням. Сервіси на сервері додатків “контактують” із шиною ESB, запускаючи асинхронні сервісні механізми й гарантовану доставку повідомлень. ПО ESB також може слугувати як засіб інтеграції, що дозволяє безлічі додатків здійснювати доступ до однієї й тієї ж транзакції в межах системи.
Іншим важливим компонентом добре спланованої архітектури SOA є централізований репозитарій, що містить довідник всіх сервісів, доступних на вашому підприємстві. Тут підійде будь-яка їхня класифікація, яка щонайкраще відповідає вашій організації. Вона повинна забезпечувати групування сервісів по бізнес-функціях, підрозділах, джерелах даних або навіть за версією вихідного коду. Використовуйте таку класифікацію, що дозволить вашим розробникам швидко знаходити сервіси, яких вони потребують для створення нових додатків.
Зазначену функціональність в SOA забезпечує реєстр, заснований на стандарті UDDI (Universal Description, Discovery and Integration), котрий можна розглядати як довідник “жовті сторінки” Web-сервісів. У ньому перераховані компанії й пов'язані з ними сервіси (всі використовувані тут стандарти - UDDI, WSDL й SOAP - перебувають у віданні організації OASIS). Дані механізми дозволяють організувати доступ ваших партнерів по бізнесу до реєстру, тим самим забезпечуючи можливість швидкої інтеграції ваших додатків.
Однак це все мрії, а поки що сервіси, орієнтовані на партнерів або клієнтів, часто складаються з безлічі більш дрібних “комплектуючих Web-сервісів”, для зшивання яких і використається UDDI. Таким чином, сьогодні UDDI використовується, наприклад, для створення сервісів між торговельними партнерами або в ланцюжках постачання.
На даний момент часу вже створено ПО реєстру сервісів, що відповідає стандарту UDDI. Це, зокрема, Registry компанії Infravio, Service Manager фірми SOA Software й Business Service Registry від Systinet. Кожний із цих продуктів функціонує як центральний інтелектуальний концентратор, за допомогою якого здійснюються систематизація сервісів SOA, доступ до них, а в деяких випадках і керування (як, наприклад, у продукті Systinet).

Сервісно-орієнтована архітектура (SOA) буде використовуватися в 50% критичних для бізнесу бізнес-додатках, розроблених в 2007 році, думають в Gartner. ДО 2010 же року частка SOA у впроваджуваних рішеннях виросте до 80%. Останнім часом популярність концепції SOA значно виросла, і її впровадження набирає оберти. Однак з ростом числа проектів росте й число компаній, що зазнали в них невдачу. Це вказує на те, що всі переваги, одержувані від SOA, мають свою ціну. Нові продукти в області SOA завоювали ринок, однак через свою незрілість найчастіше розчаровують користувачів у питаннях надійності й ефективності. Проекти виявляються досить дорогими й розтягуються на роки. З погляду IT-директорів SOA несе компанії вагомі переваги. У випадку успішного її впровадження практичними ефектами для компанії стають здатність швидше й з меншими витратами впроваджувати й інтегрувати бізнес-додатку. Однак у цієї медалі є й інша сторона: до впроваджуваних рішень доводиться висувати підвищені вимоги, а сама архітектура вимагає наявності інтеграційного ПО, тестування й налагодження (а потім і керування) якого є складним і дорогим заходом.