Конкурс Plat-Forms обещает стать мегакрутой и мегаправильной штукой. Исследовательская группа из Берлинского Свободного Университета берется провести полное сравнение всех аспектов разработки веб-систем по всем основным платформам:
- Java EE
- .NET
- PHP
- Perl
- Python
- Ruby-on-Rails
Вкратце, это будет выглядеть так. Кидается клич командам разработчиков по 3 человека, и из откликнувшихся выбираются максимум 3 команды для каждой платформы. Затем они сажаются в один большой зал, им формулируется задача, и они за 30 часов (подряд!) в обнимку с едой и подушками реализовывают ее, используя любые программные средства, какие им нравятся. Причем задачу организаторы стараются подобрать такую, чтобы она была не сильно обычной, чтобы нельзя было просто взять готовый код из интернета, но и не сильно специфичной, чтобы быть в принципе реализуемой за эти 30 часов.
Потом получившиеся система будут долго и нудно исследоваться и оцениваться по туче параметров: от производительности и надежности до легкости модификации кода. Но вот кстати, никакого финального счета не будет: результаты будут представлены по каждой "номинации" отдельно. Правда, увидим мы их не раньше мая следующего года...
Это все вкратце, а на сайте все очень подробно описано, рекомендую почитать.
От себя хочу заметить две вещи.
Почитав очень примерные требования к продукту в подробном описании конкурса, увидел среди них то, что продукт должен будет иметь SOAP-интерфейс. Это, по-моему, очень неправильно. SOAP, хоть и рекомендация W3C, на самом деле далеко не является общепринятым протоколом общения с веб-сервисами. Он, видимо, будет очень удобен в ASP.NET (потому что Microsoft — основная его движущая сила), но с ним будет сильно некомфортно на "lesscode"-платформах (Python, RoR), где предпочитают для этих целей простые REST-интерфейсы, и для которых SOAP будет реально мешащим фактором в разработке.
Другими словами, это все равно, что заставить Rails'овцев использовать MSSQL или, не знаю, ASP'шников — писать код в TextMate.
Другая вещь, которая сначала показалась тоже неправильной, но сейчас кажется наоборот — это то, что разрешается использовать любые инструменты, независимо от того, сколько они стоят денег. Я теперь думаю, что это хорошо, потому что конкурс сравнивает именно технические аспекты, и любые коэффициенты, учитывающие деньги, были бы здесь очень искусственными. Деньги любой IT-менеджер потом сам может добавить в уравнение, когда будет выбирать платформу, потому что они, в отличие от программирования, очень простой и четкий параметр.
В общем, будем ждать и следить!
Комментарии: 16
Интересно было бы посмотреть результаты, держите нас в курсе.
Откуда такая нелюбовь к SOAP? В плане - что в нем сложного для работы из того же Python?
Да дело-то не в сложности: бибилиотека есть. Основная проблема — в по-другому настроенных мозгах (из-за чего, собственно, и есть все эти очень разные платформы). Например мне, как уже совсем питонщику, идея выставления объектов свой модели сразу вовне кажется порочной по двум причинам:
Зато, думаю, Java-программисты найдут это все очень естественным.
Чем-то похоже на ICFPC, только там выбор платформы целиком на совести команды. Есть и Java и Python и Haskell много чего еще.
Зря вы так про SOAP. Веб-системы помимо массовы веб-сайтов еще и очень часто стоят в интранетах разных компаний, кроме того часто бывают веб-клиенты различных enterprise-приложений... и в подобных случаях используют как раз SOAP (как вариант — Corba, которая в PHP вообще не поддерживается).
Или просто в Python'е нету удобных инструментов для автоматической генерации WSDL?
Ага... Я чувствую, назрела статья REST vs. WS-* :-)
Одним из самых успешных проектов под моим руководством в компании Telephone.Ru было подключение нашего магазина в качестве back-end'а для интернет-магазина Самсунг (на сайте Самсунга были кнопочки "Купить" и корзина, а все заказы оформлялись в Telephone.Ru). Так вот все это было реализован именно в REST-стиле, без всякого SOAP. А зная, в каком состоянии был наш тогдашний код, я думаю, выставление его в виде SOAP-интерфейса было бы кошмаром как для нас, так и для той стороны, и заняло бы где-нибудь на год больше...
Одна из сильных сторон Питона как раз в том, что там есть огромное количество библиотек. SOAP с WSDL тоже есть.
Иван Сагалаев, тогда действительно хочется видеть статью REST vs WS-* :)))
Кстати, а почему ни слова о Corba?
Corba... Я про нее не знаю особенно много, чтобы писать :-). Но чисто архитектурно я уверен, что она так никогда широко и не разовьется по тем же причинам, что и компонентная модель Web Services. Я постараюсь все обосновать в грядущей статье (правда, нескоро).
Вообще-то, сугубо теоретически, такого рода проблемы решаются через проксик. Пишется маааленький(ие) объект(ы), интерфейс которых выставляется в SOAP, а реализация этого(их) объекта(ов) использовала бы внутренний интерфейс в REST-стиле.
Работы не много, а плюсов завались: во-первых гибкость немерянная, во-вторых выставленный наружу интерфейс очень наглядно локализован, в-третьих не нужно подстраивать внутренюю реализацию под внешние нужды, etc.
Совсем не согласен :-).
Основная прелесть SOAP (теоретически) как раз в том, что, как бы, вообще не надо ничего писать, а можно просто "опубликовать" уже написанное. Поэтому как только надо писать проксик, этот плюс уходит.
Непонятно чем это гибче. REST-интерфейс уже и так дает один уровень абстракции, отделяя публичный интерфейс от внутреннего. Если повесить еще один - гибче не будет. Или я не понял про гибкость...
А вот зато сложность поддержки возрастает, потому что появляется еще один кусок кода, который надо менять при изменениях функциональности.
Это результат все той же абстракции, которую REST-стиль предоставляет не менее удобно. Просто не нужно еще одного враппера.
Вообще-то она УЖЕ развилась :)
Сам я много работал только с PHP и Java, так вот в джаве это стандартный протокол для распределенных систем RMI-IIOP :)
Угу. Но недостатки этого подхода вы уже отлично описали. ;-) Поэтому давайте думать о SOAP именно в таком ключе: есть код, который на SOAP не рассчитан, и нужно приделать к нему SOAP. У нас, вообще-то, topic это Plat-forms, ;-) а там условие ставится именно так - SOAP нужен.
Вот для решения этой проблемы я и предложил проксик.
Alexander Lockshyn:
Тут вопрос в том, считать ли это за успех :-). Я, как насквозь человек веба, сказал бы что распределенные приложения в рамках одной платформы - это нишевое применение. А REST-подход ведь предлагают фактически для связи полностью гетерогенных систем в глобальном масштабе. Пресловутое понятие Web 2.0 с этого и началось, хотя и выродилось в "социальные" сервисы с пастельными градиентами.
Alex Efros:
Я о том и пишу - придумали левое условие, без которого жилось бы легче :-).
И вот теперь - ни Питона, ни Рельсов, ни REST :)
Да, действительно. Ни одного, то есть, современного фреймворка. Причем их притянутый за уши "признак" разделения:
... показывает, что они, кажется, и не особенно хотели. Могли бы просто написать "поскольку есть платформы на букву J и платформы на букву P, то свою цель мы выполнили".
REST - это, конечно, хорошо и правильно.
Но есть сервисы, реализованные как SOAP, и когда приходится ими пользоваться, то оказывается, чт в Питоне просто нет рабочих клиентских библиотек SOAP.
Есть устаревший SOAPpy, который не может разобрать некоторые WSDL и не работает с современными сервисами, написанными .NET.
Ещё есть более новый ZSI, который может разобрать WSDL, но не может сформировать понятный серверу запрос.
И всё. Кажется, для Питона SOAP - "зелен виноград".