Присоединяйся
Об авторе
Настоящее имя
Николай Федчик
Местоположение
Киев
Род занятий
IT Manager
Меню
RSS-лента
Развитие веб-архитектур (путь от LAMP к SOA)
Я собираю информацию для написания статьи по развитию веб-проектов и эволюции веб-архитектур.
В часности, о переходе с централизованных LAMP-решений (конечно же не без CMS Drupal) на SOA.
Черновой вариант (на украинском языке) находится и обновляется здесь:
http://www.drupal.org.ua/blog/nick-fedchik/2008/aug/07/36
В статье анализируется проблема роста LAMP-проекта и возможный эволюционный путь изменения архитектуры на SOA.
Благодарю всем кто прочитает эту статью и добавит свой отзыв (либо здесь, либо там), либо поделится ссылками на другие подобные материалы.
Особенно интересуют отзывы как программистов, системных архитекторов, так и руководителей проектов, о мотивах и причинах, которые привели к эволюционному (или революционному) изменению архитектуры веб-проектов, к смене языков разработки веб-приложений (например с php на java).
- Блог пользователя Nick Fedchik
- Войдите или зарегистрируйтесь, чтобы оставлять комментарии
Комментарии
Де сенс?
SOA, як така, це прерогатива великомаштабних комплексних рішень, де необхідно інтегрувати купу різнорідного софта писаного на різних мовах і для різних платформ, наприклад CRM+ERP+WFM що йдуть від різних розробників.
Сенсу використовувати сервісну орієнтацію для дрібних платформ, як от фронтенди сайтів OpenSource CMS - якось складно знайти.
Єдине що зустрів - більш-менш пристойне у реалізації SOA для відкритих платформ це Opentaps - нарощений з джакартівського ofBiz, та Xaware - дуже потужнга платформа та middleware. Зрозуміло все на java - так як SOA дефакто для Java/.Net ріщень так як IBM+Microsoft.
PHP - для сайтів візіток:) та опенсорсу, комерційні платформи ніколи не підуть у вихідних кодах а одною з задач SOA - інтерфейсна. Для drupal'а цього не потрібно - відкрив сорци і пишеш собі інтерфейс :).
Сенс є. Це компроміс використання поточного рішення або перехід на зовсім інше.
Я навів ситуацію, коли проект розростається зі звичайної "візитки" або ж простенького сайту для обмеженої задачі, на щось більше, де додатком є "бекенд" - такий собі випадок купи різнорідних інтерфейсів.
Звісно що є "академічно правильний підхід" - зробити все на Java/.Net з нуля, але на практиці є щось, що вже працює, і його не можна викрестили. Я про такі випадки.
Доречі, не завжди можно знайти добре альтернативне рішення.
Щодо прерогативи SOA - не зовсім погоджусь, бо технічні рішення бувають подекуди дуже гнучкими ;)
Drupal - ужасная какашка. А Drupal, как SOA - ужасная какашка в квадрате.
накакав і побіг, аргументуй хоча б перше.
Лень каждый раз пояснять, почему друпал - гавно. Могу один раз провести мастер-класс на эту тему для всех желающих. Убогое чудовище Ваш друпал.
Категорично та жодних аргументів.
>Могу один раз провести мастер-класс на эту тему
Якраз є нагода:
http://webdev.org.ua/node/595
Я только 2 числа в Киев возращаюсь, так что уж без меня :)
Yahoo, Sun, Novell використовують Друпал (великий перелік тут http://buytaert.net/tag/drupal-sites)
anycolor не використовує друпал
Странный аргумент. Использовать продукт только потому, что его кто-то использует? Вам не кажется это бредом? У Вас своя голова на плечах или Вы всегда делаете так, как делают другие?
:)
"Переход с LAMP на SOA" - звучит так же, как "Переход с TCP на HTTP". Вы сравниваете разные слои архитектуры. SOA может иметь под собой как *nix, так и win, sun, mac или какие вам угодно платформы.
Если автор имеет веб-проект, который "из обычной визитки" разросся до таких масштабов, что ему мало было, скажем, элементарного сервера с Core 2 Duo, ждем ссылку в студию :)
ps. согласен с anycolor, что друпал - какашка. Его прерогатива - хоумпейдж/личный блог, не более. Я не ставлю цель разразить холивар, это просто мое имхо.
Я сравниваю не разные слои архитектуры, а разные архитектуры.
Пример с платформами тут не уместен в принципе.
Если Вы решили, что я не знаю, какая прерогатива CMS Drupal, то Вы ошибаетесь. Если Вы решили, что целью статьи является раскрутка CMS Drupal, то тоже ошибаетесь. Просто для описания проблемы LAMP-проекта, для примера был взят CMS Drupal, но это не принципиально. Критика в адрес CMS Drupal здесь не умесна в принципе.
Принципиально я хочу рассмотреть проблему разрастания LAMP-проектов и условия изменения архитектуры на SOA к примеру (возможны ведь и другие архитектуры).
Если Вы считаете, что критерием (или причиной) разрастания проекта является недостаточность аппаратной платформы, то я сочту вас недальновидным системным архитектором, ибо причин много, и на мой взгляд аппаратные ресурсы далеко не первыми влияют на изменение архитектуры веб-проекта.
lamp - это уровень используемого софта
soa - это уровень архитектуры проекта
Чем же эти уровни не разные?
По поводу друпал - еще раз повторяю, я выразил свое мнение по поводу этой системы, не более того. Извините, если я Вас чем-то обидел.
По поводу оборудования - еще раз извиняюсь. Наверное, я не совсем правильно понял, что Вы имели в виду под разрастанием проекта.
Я считаю, что архитектура ради архитектуры - это зло. Если у Вас есть место, в котором вынесение какого-то компонента системы в сервис выгодно (с каких-то точек зрения) - пожалуйста, делайте это.
Вы говорите о "проблемах LAMP-проекта". Можно поинтересоваться, в чем состоят эти проблемы и как Вы с ними боретесь средствами SOA?
Успехов в Вашем исследовании!
Да, если быть точным, то сам по себе LAMP - это набор софта. Чтобы проще было понять типовую архитектуру веб-сайтов на LAMP, я использовал термин "LAMP-архитектура", как описание связки компонент из типичного веб-сервера, скриптовых языков типа PHP/Perl и базы данных (ах да, тут ещё и Linux - тогда корректнее будет назвать AMP-архитектура :) правда это не такой привычный термин). Поищу более подходящий термин, также буду рад другим предложениям по терминологии. Тогда софт будет отдельно, и архитектуры будут отдельно.
Сделал вывод, что описание критериев разрастания проекта сформулировано недостаточно понятно. Если кому-либо из собственной практики есть чем поделиться в качестве простого и легко понятного примера, то буду рад соавторам ;)
Думаю, что более готовый вариант статьи тогда можно будет опубликовать в каком-нибудь компьютерном журнале.
Согласен полностью, что "архитектура ради архитектуры" это не догма, я и не стараюсь такое утверждать. Но и SOA возникла не с чистого листа, этому предшествовала эволюция архитектур. И Вы, Dev, совершенно верно написали про вынесение отдельных компонент в самостоятельные сервисы. Это эволюционный шаг. Я об этом и хочу написать. И по мере возможности указывать примеры.
Что касается "проблема LAMP-проекта" - я же написал об этом в общих чертах, просмотрите ещё раз статью. Если я недостаточно понятно написал - пишите замечания, я исправлю. Если конечно Вам эта тема интересна.
Средствами SOA бороться? А что принимать за SOA-средства? XML-RPC? SOAP? JBI? JMS? Я думаю, лучше избежать такой формулировки, пусть средства останутся просто средствами, не привязанными к архитектурам, также, как и софт (см. выше).
Конкретные проблемы конкретных проектов конечно же я указывать не буду (да и вряд ли кто-либо так поступит), стараюсь абстрагироваться от конкретики. Понимаю, что анализировать конкретный пример гораздо интереснее, но...
Спасибо за пожелание успехов.
Без примеров будет сухо, описание средств xml-rpc или soap друпала можно найти в мануалах (мне так кажется, я не искал).
Возьмите конкретную возможность какого-нибудь проекта (не обязательно называть сам проект), перенесите ее на сервис и расскажите, что Вам это дало. Это будет интересно.
Чесно говоря, статья напомнила мне труды в университете, когда нужно было умнословно обыграть какую-то предметную область для курсовой работы. Сначала Вы говорите о проблематике (сайт тормозит, обрабатывает кучу разной информации извне). Приходится "виконати кластерізацію, а ще балансування навантаження між декількома серверами" (поэтому я и спрашивал по поводу оборудования, Вы осознаете при каких масштабах данных или запросов в сутки возникает такая необходимость и как часто "визитки на друпале" достигают таких масштабов?). Дальше Вы говорите толи о недостаточном тестировании, толи о правке на production версии (когда пользователь видит белый экран)... И в конце концов предлагаете все это решить, переделав архитектуру на сервисы ("... Зазначені проблеми потребують переходу від централізованої до багаторівневої розподіленої архітектури ..."). Гениально.