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

SOA (Service Oriented Architecture) стає все більш популярною архітектурою для розбудови веб-проектів середнього та великого (промислового) рівня. Можливо, коли Ви розпочинаєте власний невеличкий веб-проект, та, наприклад, обираєте CMS Drupal, то гадаю не переймаєтесь про подальший розвиток та інтеграцію, вважаючи що PHP/Drupal Вам вистачить аж занадто...

Дійсно, розпочинати новий, невеличкий (однак все пізнається у порівнянні) веб-проект, користуючись простотою мови PHP, легкістю налаштування Drupal, розробки нових модулів за допомогою Drupal API, доробки оформлення сторінок з phptemplate - це швидко і просто.

Але якщо справи з проектом йдуть добре, то він починає рости (звістно, є певна кількість самодостатніх проектів з дуже повільними темпами росту, що вони майже непомітні та вважатимуться за відсутні).

Розвиток веб-сайту як шлях до змін архітектури.
Отже, сайт стає популярним. Багато користувачів - це добре, зазвичай це мета та ознака життєздатності будь-якого веб-проекту. Зростає кількість користувачів - відповідно кількість сеансів роботи та звернень до бази даних. Користувачі завжди бажають, щоб сайт відповідав їх власним ідеалам, щоб він мав все більше функціональності. Ви, як розробник проекту, звісно йдете назустріч користувачам - розробляєте нові модулі, додаючи нову функціональність. Сайт став трохи "важким" на відгук? "Та нічого - то ж лише трохи... Мабудь більшість користувачів цього не помітять, проте я додав новий класний функціонал для соціальних груп!" - гадаєте Ви. Справді, дуже просто вивчити php, Drupal API та застосовувати ці щвидко отримані знання на практиці!

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

Завдання та процедури обміну та обробки інформації для швидкого та відмовостійкого опрацювання вимагають розподіленого, часто - асінхронного виконання окремих завдань, що призводить до утворення багаторівневих архітектур для веб-проектів (принаймні - дворівневих, це "фасад" (frontend) та "задвірки" (backend)). А ще необхідно виконати кластерізацію, а ще балансування навантаження між декількома серверами, а ще... тож чи замислювались Ви "вчора", розпочинаючи свій веб-проект, з якими архітектурними труднощами Вам прийдеться спіткнутися "завтра"? ;)

Тепер пригадайте LAMP-архітектуру взагалі, та у випадку застосування Друпалу. Централізована система виконання завдань, що зазвичай відбуваються під час сеансу роботи користувача.
Код php виконується тоді, коли до нього відбувається звернення від користувача. Так, звістно що є заплановані завдання (cron), проте вони не зменшують навантаження та не змінюють архітектуру проекту. А проект росте. Звичайна синтаксична помилка в будь-якому модулі призводить до фатальної ситуації - робота сайту призупинена, користувач бачить білий екран браузера з якимось незрозумілим надписом про ім'я файлу та номер рядку, де виникла помилка.
"Так треба було на іншому сервері відпрацювати код!" - така апеляція зазвичай гукає у відповідь. Так, треба, і так відпрацьовують, і все одно, з ростом проекту та кількості власного коду відсоток фатальних помилок значним чином не зменшується. Не переконав? То перегляньте звіти до Drupal та його модулів на предмет кількості критичних помилок ;)

Отже, з ростом Drupal-проекту зростає кількість проблем, що спричинені його централізованою архітектурою. Пригадаю ще деякі проблеми - слабка реалізація workflow (див. BPEL, WfXML) та docflow, взаємодія в різнопротокольних середовищах, керування асинхронним виконанням завдань, робота з XML.

Робимо архітектурні зміни.
Зазначені проблеми потребують переходу від централізованої до багаторівневої розподіленої архітектури. Що може запропонувати нам зараз Drupal? Це в першу чергу робота в якості "фасаду" (оформлення веб-сторінок, локалізація, орзподіл доступу до сторінок, блоків та розділів сайту, зручність в створенні та редагуванні контенту). При цьому самодостатні функціональні компоненти необхідно виносити в інше середовище, кудись на "задвірки". Для взаємодії з віддаленими службами в Drupal 6 є група модулів Services (надає API для створення веб-сервісів), що надають XML-RPC сервер та веб-сервіси (Node, System, Taxonomy, User та Views). Також є модуль SOAP Client (Enable SOAP client functionality on Drupal using nuSOAP or PHP5 SOAP Extension). Наявність цих засобів теоретично дозволяє створити дворівневу архітектуру (Drupal frontend - Drupal backend).

Відомі недоліки:
Взаємодія з ESB - не реалізовано.
Взаємодія з системою обміну повідомленнями (JMS) - не реалізовано.
Протоколи доступу до асинхронних служб типу ASAP - не реалізовано.

Drupal як портал, що використовує портлети.
PHP Portlet - цікавий засіб, але ще не дуже розвинений (принаймні я не знайшов кращих прикладів). Поки ще я не уявляю забезпечення роботи php-портлетів в Drupal безпосередньо або іншим чином.

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