Конкурс Plat-Forms обещает стать мегакрутой и мегаправильной штукой. Исследовательская группа из Берлинского Свободного Университета берется провести полное сравнение всех аспектов разработки веб-систем по всем основным платформам:

Вкратце, это будет выглядеть так. Кидается клич командам разработчиков по 3 человека, и из откликнувшихся выбираются максимум 3 команды для каждой платформы. Затем они сажаются в один большой зал, им формулируется задача, и они за 30 часов (подряд!) в обнимку с едой и подушками реализовывают ее, используя любые программные средства, какие им нравятся. Причем задачу организаторы стараются подобрать такую, чтобы она была не сильно обычной, чтобы нельзя было просто взять готовый код из интернета, но и не сильно специфичной, чтобы быть в принципе реализуемой за эти 30 часов.

Потом получившиеся система будут долго и нудно исследоваться и оцениваться по туче параметров: от производительности и надежности до легкости модификации кода. Но вот кстати, никакого финального счета не будет: результаты будут представлены по каждой "номинации" отдельно. Правда, увидим мы их не раньше мая следующего года...

Это все вкратце, а на сайте все очень подробно описано, рекомендую почитать.

От себя хочу заметить две вещи.

В общем, будем ждать и следить!

Комментарии: 16

  1. cactusinside

    Интересно было бы посмотреть результаты, держите нас в курсе.

  2. Сергей Петров

    Откуда такая нелюбовь к SOAP? В плане - что в нем сложного для работы из того же Python?

  3. Иван Сагалаев

    Да дело-то не в сложности: бибилиотека есть. Основная проблема — в по-другому настроенных мозгах (из-за чего, собственно, и есть все эти очень разные платформы). Например мне, как уже совсем питонщику, идея выставления объектов свой модели сразу вовне кажется порочной по двум причинам:

    • это провоцирует очень неудобный интерфейс для моих пользователей, потому что им придется вникать в суть моей объектной модели
    • поскольку в Питоне нет скрытия данных, свои объекты мне вообще будет страшновато выставлять на полный публичный доступ (ОО в Питоне используется не как закрытый бастион нерушимой функциональности)

    Зато, думаю, Java-программисты найдут это все очень естественным.

  4. Max Ischenko

    Чем-то похоже на ICFPC, только там выбор платформы целиком на совести команды. Есть и Java и Python и Haskell много чего еще.

  5. Alexander Lockshyn

    Зря вы так про SOAP. Веб-системы помимо массовы веб-сайтов еще и очень часто стоят в интранетах разных компаний, кроме того часто бывают веб-клиенты различных enterprise-приложений... и в подобных случаях используют как раз SOAP (как вариант — Corba, которая в PHP вообще не поддерживается).
    Или просто в Python'е нету удобных инструментов для автоматической генерации WSDL?

  6. Иван Сагалаев

    Ага... Я чувствую, назрела статья REST vs. WS-* :-)

    Веб-системы помимо массовы веб-сайтов еще и очень часто стоят в интранетах разных компаний, кроме того часто бывают веб-клиенты различных enterprise-приложений… и в подобных случаях используют как раз SOAP

    Одним из самых успешных проектов под моим руководством в компании Telephone.Ru было подключение нашего магазина в качестве back-end'а для интернет-магазина Самсунг (на сайте Самсунга были кнопочки "Купить" и корзина, а все заказы оформлялись в Telephone.Ru). Так вот все это было реализован именно в REST-стиле, без всякого SOAP. А зная, в каком состоянии был наш тогдашний код, я думаю, выставление его в виде SOAP-интерфейса было бы кошмаром как для нас, так и для той стороны, и заняло бы где-нибудь на год больше...

    Или просто в Python’е нету удобных инструментов для автоматической генерации WSDL?

    Одна из сильных сторон Питона как раз в том, что там есть огромное количество библиотек. SOAP с WSDL тоже есть.

  7. Alexander Lockshyn

    Иван Сагалаев, тогда действительно хочется видеть статью REST vs WS-* :)))

    Кстати, а почему ни слова о Corba?

  8. Иван Сагалаев

    Corba... Я про нее не знаю особенно много, чтобы писать :-). Но чисто архитектурно я уверен, что она так никогда широко и не разовьется по тем же причинам, что и компонентная модель Web Services. Я постараюсь все обосновать в грядущей статье (правда, нескоро).

  9. Alex Efros

    Вообще-то, сугубо теоретически, такого рода проблемы решаются через проксик. Пишется маааленький(ие) объект(ы), интерфейс которых выставляется в SOAP, а реализация этого(их) объекта(ов) использовала бы внутренний интерфейс в REST-стиле.

    Работы не много, а плюсов завались: во-первых гибкость немерянная, во-вторых выставленный наружу интерфейс очень наглядно локализован, в-третьих не нужно подстраивать внутренюю реализацию под внешние нужды, etc.

  10. Иван Сагалаев

    Совсем не согласен :-).

    Основная прелесть SOAP (теоретически) как раз в том, что, как бы, вообще не надо ничего писать, а можно просто "опубликовать" уже написанное. Поэтому как только надо писать проксик, этот плюс уходит.

    Непонятно чем это гибче. REST-интерфейс уже и так дает один уровень абстракции, отделяя публичный интерфейс от внутреннего. Если повесить еще один - гибче не будет. Или я не понял про гибкость...

    А вот зато сложность поддержки возрастает, потому что появляется еще один кусок кода, который надо менять при изменениях функциональности.

    не нужно подстраивать внутренюю реализацию под внешние нужды

    Это результат все той же абстракции, которую REST-стиль предоставляет не менее удобно. Просто не нужно еще одного враппера.

  11. Alexander Lockshyn

    Corba… Я про нее не знаю особенно много, чтобы писать :-). Но чисто архитектурно я уверен, что она так никогда широко и не разовьется по тем же причинам, что и компонентная модель Web Services.

    Вообще-то она УЖЕ развилась :)
    Сам я много работал только с PHP и Java, так вот в джаве это стандартный протокол для распределенных систем RMI-IIOP :)

  12. Alex Efros

    Основная прелесть SOAP (теоретически) как раз в том, что, как бы, вообще не надо ничего писать, а можно просто “опубликовать” уже написанное.

    Угу. Но недостатки этого подхода вы уже отлично описали. ;-) Поэтому давайте думать о SOAP именно в таком ключе: есть код, который на SOAP не рассчитан, и нужно приделать к нему SOAP. У нас, вообще-то, topic это Plat-forms, ;-) а там условие ставится именно так - SOAP нужен.

    Вот для решения этой проблемы я и предложил проксик.

  13. Иван Сагалаев

    Alexander Lockshyn:

    Вообще-то она УЖЕ развилась :)
    Сам я много работал только с PHP и Java, так вот в джаве это стандартный протокол для распределенных систем RMI-IIOP :)

    Тут вопрос в том, считать ли это за успех :-). Я, как насквозь человек веба, сказал бы что распределенные приложения в рамках одной платформы - это нишевое применение. А REST-подход ведь предлагают фактически для связи полностью гетерогенных систем в глобальном масштабе. Пресловутое понятие Web 2.0 с этого и началось, хотя и выродилось в "социальные" сервисы с пастельными градиентами.

    Alex Efros:

    У нас, вообще-то, topic это Plat-forms, ;-) а там условие ставится именно так - SOAP нужен.

    Я о том и пишу - придумали левое условие, без которого жилось бы легче :-).

  14. Oleg Andreev

    И вот теперь - ни Питона, ни Рельсов, ни REST :)

  15. Иван Сагалаев

    Да, действительно. Ни одного, то есть, современного фреймворка. Причем их притянутый за уши "признак" разделения:

    However, since both a "conventional" platform (based on a statically typed language: Java) and two platforms based on scripting languages (Perl, PHP) are present, the contest will fulfill its intended purpose perfectly.

    ... показывает, что они, кажется, и не особенно хотели. Могли бы просто написать "поскольку есть платформы на букву J и платформы на букву P, то свою цель мы выполнили".

  16. Александр Пугачев

    REST - это, конечно, хорошо и правильно.

    Но есть сервисы, реализованные как SOAP, и когда приходится ими пользоваться, то оказывается, чт в Питоне просто нет рабочих клиентских библиотек SOAP.

    Есть устаревший SOAPpy, который не может разобрать некоторые WSDL и не работает с современными сервисами, написанными .NET.
    Ещё есть более новый ZSI, который может разобрать WSDL, но не может сформировать понятный серверу запрос.

    И всё. Кажется, для Питона SOAP - "зелен виноград".

Добавить комментарий