Helma — и снова серверный JavaScript

    Немного ранее я уже рассказывал о разработке компании Aptana — серверной платформы Jaxer, которая позволяет развёртывать приложения на JavaScript на стороне сервера, и объединять таким образом код клиентской и серверной стороны. Конечно, есть много спорностей в таком подходе, как и вообще применимости такого языка как JavaScript для разработки полноценных веб-приложений на сервере, но это не останавливает разработчиков — несмотря на ограничения, вполне можно разрабатывать интереснейшие приложения. Но вот уникальна ли эта платформа? Теперь нет.

    Открытый проект Helma — написанная на Java платформа для исполнения серверных приложений на JavaScript. Сейчас поддерживается версия 1.7, однако с развитием движка Rhino, который отвечает во всех проектах подобного рода за интерпретацию JS, будем ожидать, что и вторая версия будет поддерживаться. Платформа обладает и встроенным веб-сервером, в качестве которого используется Jetty, и даже собственная объектно-ориентированная база данных (на основе XML), которая прозрачно интегрирована в платформу и позволяет сохранять и кешировать объекты между сессиями. Также есть встроенные средства отладки приложений, при этом все доступно через веб-интерфейс.


    Сами приложения для Helma это удивительная смесь статических файлов, HTML-а, основного кода на JavaScript и других служебных файлов, раскиданных по определённой схеме в десятке служебных директорий. Подход достаточно нетривиален и старается смешивать некоторые возможности из Java и .NET, однако на первый взгляд это все запутано, поэтому придётся разбираться с структурой файлов и их форматом, что достаточно непросто. В этом есть существенный минус платформы, если её сравнивать с Aptana Jaxer.

    Но есть и позитивные отличия. К примеру, в Helma есть собственный фреймворк (да, точно такой же подход и в решении от Aptana), который при помощи модуля Helma Object Publisher позволяет отображать интерфейсы подключаемых Java компонент в приложения на JavaScript. Это позволит при некоторых усилиях использовать множество уже готовых серверных компонент на Java, а это значительно расширяет возможности приложений. И, в отличие от того же решения от Aptana, нам изначально доступны некоторые компоненты, которые очень полезны для разработки серьёзных решений — поисковый модуль Apache Lucene, модули для работы с базами данных, протоколами SSH, FTP, HTTP, модуль для работы с почтой, рисование графиков и диаграмм, работа с файлами и изображениями и несколько других. В принципе, интеграция и других модулей не должна быть очень сложной, поэтому Helm-у можно даже рассматривать как прокси-провайдер для связи Java-пакетов с приложениями на других языках, возможно даже эту часть можно подключить к Aptana, соединив преимущества обоих платформ.

    В состав платформы входит и полноценная среда для отладки приложений без использования дополнительных приложений — все операции (точки остановки, просмотр стека, пошаговая отладка) проводятся прямо в браузере. В дополнение к отладчику есть и инспектор для HopObjects (это основные объекты платформы, доступные в приложении, часть из них являются абстракцией к интерфейсам самой платформы, часть — те самые Java — компоненты, что доступны в JavaScript через Helma Object Publisher), а также небольшая, но достаточно развитая оболочка для работы с SQL-базами данных, которые подключаются через JDBC.



    К сожалению, подробного описания платформы нет, хотя документации для разработчика достаточно много, поэтому я пытался разобраться в общей архитектуре по обрывкам описания в примерах, исследовал сам дистрибутив и другими путями. Возможно что-то я упустил, о чем-то не рассказал так подробно, как стоило бы — но это не так важно и не суть этого материала. В чем-то платформа Helma уступает Jaxer — например, в удобстве развёртывания, в интеграции с другими серверами, но есть и достаточно много уникальных моментов, делающих это решение интересным для разработки приложений. Из коробки доступно много интересных возможностей, больше, чем в конкурирующих средах, а наличие встроенных мощных средств отладки позволяет использовать Helma как среду для быстрого прототипирования и проверки новых идей, потом воплощая их уже на рабочей платформе. Выбор, как всегда, за вами!

    P.S. Оригинал публикации в моем блоге.
    Поделиться публикацией

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 45

      +1
      Интересный подход, но, будет-ли он востребован, учитывая количество существующих серверных языков программирования?
        0
        В Google пишут серверные приложения на JS, а спека ES4 ооочень крутая и делает его привлекательнее многих других "серверных языков программирования".
        0
        Совершенно верно замечено! Существуют столько серверных языков и очень неплохих... чем этот отличается? короче баян языков...
          0
          вас послушать, то должен быть только ОДИН серверный язык, да?
            0
            Меня послушать... какое отличие? в чем революция? мне например вообще плевать на каком языке писать, я уже на стольких писал, что сбился со счета сколько я из знаю :). Я считаю вначале архитектура потом язык.
              0
              "мне например плевать, на какой машине ездить, я уже на стольких ездил, что со счёта сбился. главное не машина, а уровень вождения"

              когда речь идёт не о стоянии в пробке, а о формуле-1, то машина играет не менее ключевую роль, чем умение водить. для тех, кто каждый день клепает корпоративные сайтики-порталы разницы действительно нет.
                0
                Ооо, класс, про формулу-1 мне понравилось... только вот заметь КЛАССНЫЙ гонщик выбирает всегда классную машину...
                Потому что г..о извинте его не устроит, хотя неплохой результат он покажет и на тазике.
                  0
                  Я кстати выбираю тот язык, который больше подходит под разработанную архитектуру проекта. т е хорошая машина в ф-1, для хорошего пилота + та что подходит под стиль вождения.
                    0
                    В свою очередь, на загруженном бездорожье F-1 заедет не далее ближайшей кочки.
                    Всему своё место.
                      0
                      А нехрен на формуле по народ.ру и шаред-хостингам бегать) Не можешь построить трассу - не пользуй форумулу.
                        0
                        Вы это к чему сказали?
                        Вообще-то я веду к тому, что использовать Java для одностраничного сайта-визитки — глупо. Равно как и использовать Helma для построения высоко нагруженных сервисов вроде Google или Yahoo.
                        Кроме того, в последнее время инструмент выбирают не только учитывая скорость его работы, но и учитывая скорость (удобство) разработки (как пример - RoR).

                        И, да, автомобили выбирают для задач, как и инструмент. Но не задачу для инструмента.
                        Никто в здравом уме не будет использовать болиды формулы-1 для перевозов огромного количества груза. И руководству глубоко плевать на то, насколько крут этот болид, и насколько опытен пилот — он загнется под первым же контейнером хабраэффекта. Такие машины — нужны единицам.
                        Теперь понятнее, что я пытаюсь донести?
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Вот интересно, у нас в России используется Java как серверный язык вэб приложений или ничтожно редко???
                0
                Использовать серверный JS так же круто, как брится топором. Вот только бессмысленно.
                  0
                  нее, я про java2se...
                    0
                    Ах, тогда извините :) В контексте данного топика вполне логично решил, что вы всё таки о JS :)
                      0
                      Для веб приложений используется всё же JEE, а не Java SE. Dice.com по запросу Java выдаёт наибольшее количество вакансий(на порядок больше Ruby/Python/PHP) - это рынок US. Так что если идти в аутсорсинговую контору, то там от Вас в девяти случаях из десяти будут требовать Java или .NET.

                      Наш IT-рынок труда пока только формируется. Хороших специалистов нехватает везде, буть то 1C, Bitrix или JEE.
                        0
                        Разве JEE? Не знал, мне казалось JEE для оч глобальных проектов, и всяко не в вэбе...
                          0
                          JEE содержит множество API для самых разных целей. Один из них(javax.servlet) как раз служит для создания Web-приложений.
                    0
                    Java это один из самых популярный языков, если не самый популярный в мире:

                    http://www.langpop.com/
                    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
                    http://www.ohloh.net/languages/compare

                    используется ли он в Россиии (СНГ)? трудно оценить, но у россиян свой менталитет. в России, например, популярен браузер Опера... но у аутсорсных компаний подавляющее кол-во проектов на Java
                      0
                      Самый популярный, вы удивитесь, это как раз JavaScript.
                        0
                        Вполне возможно, не буду спорить
                      0
                      если брать не аутсорс для буржуев, а внутренние проекты, то почти все биллинговые системы пишутся на яве, софт для сотовых операторов, банковский софт и т.д.
                      0
                      давно была идея сделать что-нить серверное на spidermonkey как cgi. с удовольствием посмотрю на данные проекты, спасибо.
                        0
                        JavaScript - отличнейший язык! Я сам поклонник Ruby, однако видел в том же prototype, что с помощью нехитрых вещей можно реализовать те же map, each etc для массивов. Система метапрограммирования позволяет слепить все что нужно
                          0
                          JavaScript - один из самых уродливых и отвратных языков. Использовать его для серверной части просто абсурдно.
                            0
                            Предложите лучше:) Прелесть его в том что, если что-то не нравиться, то можно поправить, а вот всякие Java/PHP как были "глобальными и надежными" так ими и остануться.
                              0
                              О критике JavaScript писалось очень много. Просто историчеки так сложилось, что он стал единственным языком для управления объектами в браузере. Для серверной части, где ограничения на язык не существует, выбор JS более чем неадекватен.
                                0
                                О недостатках JavaScript не видел статей уже последние несколько лет. Единственный весомый недостаток - различная (причем кривая) реализация в разных браузерах, что для серверных решений не имеет значения. Ограничение на язык серверной части есть - это предоставление хостинга и распространённость языка, второй критерий это как раз лакомый кусочек.
                              0
                              Чем же он так плох?
                                0
                                Вы или аргументируйте или идите на... почитайте спецификацию ES4.
                                  0
                                  Аргументы? Пожалуйста!

                                  1. Динамический (скриптовый). Эволюция структурных языков шла в направлении усиления контроля над действиями программиста, тогда как скриптовые языки исходили из соображений удобства программирования. Удобство и правильность не всегда совместимы (взгляните например спецификацию Ада). В результате статистика ошибок в динамическом языке в несколько раз больше.
                                  2. Нестрогий контроль типов. Меньше ошибок удается отследить в момент компиляции (которой судя по всему нет). Кстати, все нововведения ES4 касаются как раз структур данных и контроля типов, но опять же, не строго.
                                  3. Собственно runtime-контроль. Фазы компиляции и предварительной проверки, похоже, нет. Все ошибки - в момент интерпретации.
                                  4. Сложность и избыточность (неминимальность). Отсутствие минимального "ядра" языка. Кстати, на сайте я так и не нашел строгого документа-спецификации языка. Взгляните, например, спецификацию Java.
                                  5. Более чем сомнительное быстродействие имплементаций.
                                  6. Несовместимость с предыдущими версиями языка.
                                    +1
                                    Это уже больше похоже на то, что вы не конкретно JS ругаете, а все скриптовые языки поголовно
                                      –1
                                      В принципе - да. Не долюбливаю я их. Область их применения сильно ограничена. Возможно для рендеринга веб страницы и sql запросов более-менее подходит, но для серьезных проектов - увы. Хотя бы для написания фреймворков и api для тех же языков.
                                        0
                                        что для вас серьезный проект? LinkedIn, MoйКруг, Википедия, SourceForge, и Yahoo.Answers для вас большие серьезные проекты?
                                          0
                                          С точки зрения программной имплементации эти проекты не являются сложными. Стандартный набор - фронтенд, база данных, индексатор. Вся сложность этих проектов - в обеспечении горизонтальной масштабируемости.

                                          Сложный проект - это система резервирования авиабилетов Amadeus. Система обслуживания авиалиний. Система транзакций ServiRed (с кучей фронтендов). Софтина любого банка сложнее в сто раз любого из этих проектов. Если говорить о нагрузках, то никакая википедия не сравнится по количеству запросов с биллинговой системой мобильного оператора.
                                          Так что! PHP - это вершина айсберга для клепания дырявых ;) страничек.
                                      0
                                      если мне не изменяет память, то и питон динамический, и руби, и AS, и даже та самая java так себе, она где-то посередине между чистой динамикой и статикой (теми, кто в машинный код компилируется сразу). Ага, и РНР также динамический.
                                        0
                                        А еще есть Perl и Groovy. А Вы не задавались вопросом - нафиг столько языков для реализации одной и той же задачи? Это топтание на месте - нет никакой эволюции и радикально нового шага: ассемблер - фортран - алгол - паскаль - си - си++ - java/c# - дальше что? Скриптовое семейтво? Похоже немного на вырождение.

                                        Тот JavaScript, который был изначально встроен в браузер Netscape не имел даже нормальной спецификации. Все последующие развитие языка было связано со стабилизацией синтаксиса при остающейся совместимости с предыдущими версиями. Если бы тот же питон был взят за основу динамических страниц, мы бы избежали сегодня большого числа проблем.
                                          0
                                          ассемблер - фортран - алгол - паскаль - си - си++ - java/c#

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

                                          Что же дальше? Однозначно языки с динамической типизацией и переход к декларативности (C# 3.0 тому подтверждение, хоть и мейнстрим-язык, но тем не менее...). Все проблемы динамических языков, которые вы привели не столь важны, они легко решаются. Да проблемы есть, но они несколько в другом, они решаются и динамика потихоньку просачиваются в software factory. Скриптовые языки здесь ни причем:)

                                          Насчет JS - да жосткого стандарта ему не помешало бы, но семантически язык очень мощный, потенциально мощнее всей java вместе взятой как минимум. Но только не в том виде, в котором он есть сейчас.
                                            0
                                            Это понятно, что маркетологи пытаются завлечь программистов, маня удобством и краткостью кода (программисты ленивые и много писАть не любят). C# - яркий тому пример. В отличие от аскетичной и минималистичной Java, C# постоянно модифицируется в сторону угождения программистам и превращается в помойку. И даже не маркетологи определяют дальнейшую эволюцию, а программисты, которые выросли на языках типа JS.

                                            Основной вопрос - на кой черт? Что динамические языки предлагают такого, чего нет в структурных? Никто экономически не доказал выгодность перехода от структурных языков к динамическим. Более того, существуют четкие аргументы против этого, которые не так просто решить, как кажется. В средах J2EE тоже используется декларативность и скриптинг, но в отличие от JS и иже с ними, она базируется на XML, который строго проверяется на валидность.
                                              0
                                              Да, я вижу вы мыслите очень прагматично, и наверное это во многом правильный подход. C#, да это помойка, но я никак не могу назвать Java "аскетичной и минималистичной". Аскетичные и минималистичные языки в моем представлении - Lisp, Forth. Дизайн Java идеально подходит для студентов, которые получили диплом программиста, но недопоняли C/C++ и их можно быстро переучить до нужной кондиции, не ломая их представления о синтаксисе и подходе вообще. Java завязана на библиотеках, а они отнюдь и не минималистичны и не аскетичны.

                                              Исследователи языков программирования уже не одно десятилетия пророчат лидерство декларативного подхода. Конечно у них есть свои аргументы "за". Ответом вопрос "на какой черт" наверное будет то что будет требоваться меньше строк кода для выражения мыслей. Меньше кода, меньше ошибок и тд... А еще имеет место уменьшение количества сущностей, что так же способствует пониманию. Хочу еще уточнить, что структурный подход это не антипод к динамическому:) Насчет валидности XML я что-то не понял. Так же как мы валидируем XML, мы можем и валидировать, скажем JSON, коль речь о JS зашла, кстати предмет нашего обсуждения имеет очень благородные корни - язык Self.
                                0
                                перетягивание каната…
                                возможно это подкупит тех программистов, что начали свой путь с JavaScript… и смогут перейти на серверную часть с минимальными… напряжениями в мозгу…
                                но будет ли это переход навсегда? думаю нет, сейчас мода… и тенденция к улучшению выразительности языков…
                                поэтому после перехода на сервер с знакомым языком, порграммист начнет искать удобство работы там и, как видится. предпочтет более выгодный путь (язык)…
                                выбор программиста может испортить лишь маркетолог, который создаст видимую популярность и превосходство того или иного языка на тот момент…
                                а потом — законченные проекты, которые надо поддерживать и дорого переделать… и пошло поехало…

                                  +1
                                  что есть помимо Helma — https://wiki.mozilla.org/ServerJS#Implementations

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое