Так я ж и не говорю, что SOAP — плохо. Я просто сказал, что пример использования плохой.
К примеру, на одном из моих проектов SOAP используется для предоставления API по управлению пользовательским контентом. Т.е. пользователь может залогиниться на сайт и там управлять своим контентом (от десятка до сотни тысяч единиц контента), а может использовать SOAP API для интеграции со своим софтом или просто поюзать десктопную софтинку, которая говорит с проектом по этому SOAP API. И мне хорошо (снижается нагрузка за счет отсутсвия рендеринга страниц) и пользователю удобно.
Собственно, если исходить из посылки, что нужно иметь вот это:
«При помощи этой библиотеки вы можете, например, строить страницу вашего сайта из блоков, как из конструктора. Каждый блок запрашивается через SOAP отдельно и независимо от других, при этом все запросы происходят параллельно. Если один из блогов не уложился в отведенное ему время (тайм-аут), то его можно не отображать на странице.»
то гораздо лучше подойдут nginx'овские ssi.
С их помощью можно:
— Одновременное, параллельное выполнение запросов
— Реконнект при невозможности установления связи (даже лучше, можно отправлять иметь пул серверов и балансировать запросы между ними, если один сервер не ответил, то можно отправить запрос на другой)
— Поддержка тайм-аута на получение данных
+ к этому нет оверхеда на использование SOAP (кодирование/декодирование ответа, оверхед на сами SOAP месседжы и т.п.). Можно еще положить эти самые сгенеренные блоки в memcached и попросить nginx проверять их там; если найдется закешированный блок, то до php денло вообще не дойдет; блоки можно кешировать с различным TTL.
В общем, я не вижу ни одного преимущества этого SOAP решения против описанного мной, кроме немного более удобной передачи аргументов в вызов, однако на этом и все.
Этот зверь пока спит у меня в svn. Версия вполне рабочая, не хватает мелких вещей вроде документации и описания изменений в шаблонизаторе. Дима прав, несколько месяцев по нему я ничего не делал - занят очень. Надо будет все-таки собраться и подшлифовать остатки.
Если вкратце про 2.0, то:
- работает только под php5
- в качестве хранилища данных может использовать MySQL и sqlite. Остальные мне пока были без надобности, но дописать легко.
- Появился демон, написанный опять же на php, который раотает как ftp-сервер. Но через него можно управлять структурой и содержимым сайта. Для клиента это все выглядит как файловые операции (создать/удалить/отредактировать папку/файл).
- появился настраиваемый анализатор логов веб сервера.
- поддержка различных методов кеширования (это в смысле, если установлен memcached, то изобретать велосипед в виде импользования файлового кеша не нужно)
- протестирован и нормально рабоатет в FastCGI (тестировал nginx + (php-fpm или spawn-fcgi от lighthttpd))
- есть возможность настроить шаблонизатор в режим, когда каждый помеченный блок отдается на обработку отдельному fcgi-процессу через отдельный запрос. Это позволяет параллельно обрабатывать части одной и той же страницы или выносить различный функционал на разные хосты. В некоторых случаях имеет глубокий смысл :)
- вся эта красота стала работать быстрее.
Вкратце, вот такие пироги. Кроме, собственно, полностью переписанного кода появились сервисные утилитки в виде того же анализатора логов и ftp-сервера для управления сайтом хоть из консоли...
В общем, не могу сказать, что весь этот функционал можно будет использовать на shared хостинге, скорее наоборот. Но базовый функционал можно спокойно использовать на большинстве среднестатистических php+MySQL хостингов.
К примеру, на одном из моих проектов SOAP используется для предоставления API по управлению пользовательским контентом. Т.е. пользователь может залогиниться на сайт и там управлять своим контентом (от десятка до сотни тысяч единиц контента), а может использовать SOAP API для интеграции со своим софтом или просто поюзать десктопную софтинку, которая говорит с проектом по этому SOAP API. И мне хорошо (снижается нагрузка за счет отсутсвия рендеринга страниц) и пользователю удобно.
«При помощи этой библиотеки вы можете, например, строить страницу вашего сайта из блоков, как из конструктора. Каждый блок запрашивается через SOAP отдельно и независимо от других, при этом все запросы происходят параллельно. Если один из блогов не уложился в отведенное ему время (тайм-аут), то его можно не отображать на странице.»
то гораздо лучше подойдут nginx'овские ssi.
С их помощью можно:
— Одновременное, параллельное выполнение запросов
— Реконнект при невозможности установления связи (даже лучше, можно отправлять иметь пул серверов и балансировать запросы между ними, если один сервер не ответил, то можно отправить запрос на другой)
— Поддержка тайм-аута на получение данных
+ к этому нет оверхеда на использование SOAP (кодирование/декодирование ответа, оверхед на сами SOAP месседжы и т.п.). Можно еще положить эти самые сгенеренные блоки в memcached и попросить nginx проверять их там; если найдется закешированный блок, то до php денло вообще не дойдет; блоки можно кешировать с различным TTL.
В общем, я не вижу ни одного преимущества этого SOAP решения против описанного мной, кроме немного более удобной передачи аргументов в вызов, однако на этом и все.
NOW() + INTERVAL 1 DAY
NOW() — INTERVAL 1 MONTH
и т.п.
Если вкратце про 2.0, то:
- работает только под php5
- в качестве хранилища данных может использовать MySQL и sqlite. Остальные мне пока были без надобности, но дописать легко.
- Появился демон, написанный опять же на php, который раотает как ftp-сервер. Но через него можно управлять структурой и содержимым сайта. Для клиента это все выглядит как файловые операции (создать/удалить/отредактировать папку/файл).
- появился настраиваемый анализатор логов веб сервера.
- поддержка различных методов кеширования (это в смысле, если установлен memcached, то изобретать велосипед в виде импользования файлового кеша не нужно)
- протестирован и нормально рабоатет в FastCGI (тестировал nginx + (php-fpm или spawn-fcgi от lighthttpd))
- есть возможность настроить шаблонизатор в режим, когда каждый помеченный блок отдается на обработку отдельному fcgi-процессу через отдельный запрос. Это позволяет параллельно обрабатывать части одной и той же страницы или выносить различный функционал на разные хосты. В некоторых случаях имеет глубокий смысл :)
- вся эта красота стала работать быстрее.
Вкратце, вот такие пироги. Кроме, собственно, полностью переписанного кода появились сервисные утилитки в виде того же анализатора логов и ftp-сервера для управления сайтом хоть из консоли...
В общем, не могу сказать, что весь этот функционал можно будет использовать на shared хостинге, скорее наоборот. Но базовый функционал можно спокойно использовать на большинстве среднестатистических php+MySQL хостингов.