Возможно кто-то уже сталкивался с подобным выбором, поэтому хотелось бы услышать мнение коллег... Ситуация такова: с нуля будет создаваться некоторый продукт, ключевые свойства которого я постараюсь перечислить ниже. Выбор всех техологий полностью свободен, уникальный шанс сделать всё правильно
Итак, свойства:
Это будет веб-приложение, единственный интерфейс — через броузер, AJAX обязателен.
Только для Windows, причём про антикварные версии (до 2000) можно не думать.
Предполагается запуск в виде Windows-сервиса.
Ресурсоёмкость приложения небольшая (никаких сложных вычислений или больших объёмов данных).
Трафикоёмкость тоже небольшая (никаких пересылок больших файлов, суперчастых обновлений, аудио/видео).
Количество одновременных пользователей — от 1 до 20.
Потребуется база данных, но требования к ней очень невысоки, так что с точки зрения производительности подойдёт любая (MySQL, PostgreSQL, SQLite, HSQL, etc.).
Приложение будет коммерческим, то есть надо учитывть лицензионные требования всех компонентов (БД, например).
Приложение должно обладать хоть какой-то защитой от несанкционированного копирования.
Цель, как обычно, минимизировать затраты ресурсов на разработку и поддержку такого предложения. Предпочтений по технологиям — никаких, на данном этапе рассматриваются все варианты, от Delphi + Indy + FireBird до Java + Jetty + HSQL (JIT-compiled).
Буду благодарен за любые цензурные соображения по теме
Здравствуйте, Firstborn, Вы писали:
F>Возможно кто-то уже сталкивался с подобным выбором, поэтому хотелось бы услышать мнение коллег... Ситуация такова: с нуля будет создаваться некоторый продукт, ключевые свойства которого я постараюсь перечислить ниже. Выбор всех техологий полностью свободен, уникальный шанс сделать всё правильно
F>Итак, свойства:
F>
F>Это будет веб-приложение, единственный интерфейс — через броузер, AJAX обязателен. F>Только для Windows, причём про антикварные версии (до 2000) можно не думать. F>Предполагается запуск в виде Windows-сервиса. F>Ресурсоёмкость приложения небольшая (никаких сложных вычислений или больших объёмов данных). F>Трафикоёмкость тоже небольшая (никаких пересылок больших файлов, суперчастых обновлений, аудио/видео). F>Количество одновременных пользователей — от 1 до 20. F>Потребуется база данных, но требования к ней очень невысоки, так что с точки зрения производительности подойдёт любая (MySQL, PostgreSQL, SQLite, HSQL, etc.). F>Приложение будет коммерческим, то есть надо учитывть лицензионные требования всех компонентов (БД, например). F>Приложение должно обладать хоть какой-то защитой от несанкционированного копирования. F>
F>Цель, как обычно, минимизировать затраты ресурсов на разработку и поддержку такого предложения. Предпочтений по технологиям — никаких, на данном этапе рассматриваются все варианты, от Delphi + Indy + FireBird до Java + Jetty + HSQL (JIT-compiled).
F>Буду благодарен за любые цензурные соображения по теме
А может .NET и SQL Server 2005 ?
Поподробнее задачи опишите, а то не очень понятно зачем запуск в виде Windows сервиса и web интерфейс.
Совершенно не понятно что нужно. Спектр технологий колеблется от PHP до JEE/.NET.
БД — либо MySQL (традиционно), либо PostgreSQL (лично мне более приятно с это работать).
Все описанные требования — стандарт де-факто. Единственное, отмечу. Если речь идет о системе на продажу, глупо замыкаться в рамках технологий Windows. Технологии Windows в данном контексте это Delphi и .NET. Лучше выбрать что-нибудь скриптовое (PHP, Ruby, Python)или Java. Для всех есть отличные среды разработки.
Здравствуйте, gandjustas, Вы писали:
G>А может .NET и SQL Server 2005 ?
Такой вариант несколько смущает необходимостью выкачивания многомегабайтного фрэймворка, опросы показывают, что более чем у половины нашей аудитории он не стоит.
G>Поподробнее задачи опишите, а то не очень понятно зачем запуск в виде Windows сервиса и web интерфейс.
Веб-интерфейс есть требование заказчика. Сервис — логичный вариант для случая, когда видимая часть приложения есть контент в окне броузера; сам "сервер" в это время крутится в виде сервиса и ничем себя не проявляет, ничем не смущает неискушённого юзера. Суть в том, что заметная часть инсталляций обещает быть однопользовательской, т.е. юзер скачал инсталляцию, проинсталлировал N раз нажав кнопку Next, кликнул на созданный в результате инсталляции ярлычок на десктопе, открылся броузер и там наше приложение. Всё, ничего больше юзер не видит и не должен видеть.
При таком сценарии, какие ещё могут быть варианты, кроме сервиса?
Что же касается более подробного описания задачи — с удовольствием, намекните только что ещё Вам интересно.
Здравствуйте, LeonidV, Вы писали:
LV>Совершенно не понятно что нужно. Спектр технологий колеблется от PHP до JEE/.NET.
.NET несколько смущает необходимостью выкачивания многомегабайтного фрэймворка, опросы показывают, что более чем у половины нашей аудитории он не стоит.
LV>БД — либо MySQL (традиционно), либо PostgreSQL (лично мне более приятно с это работать).
А вот тут возникают упомянутые в изначальном посте вопросы с лицензией. Насчёт PostgreSQL не уверен, но насколько мне известно MySQL не особенно позволяет бандлить себя с коммерческим приложением. Или я не прав?
LV>Если речь идет о системе на продажу, глупо замыкаться в рамках технологий Windows.
Может и глупо, но market research говорит, что 94% потенциальной аудитории используют Windows 2000/XP/Vista.
LV>Технологии Windows в данном контексте это Delphi и .NET.
О .NET я уже написал, так что Delphi остаётся одним из основных претендентов... пока.
LV>Лучше выбрать что-нибудь скриптовое (PHP, Ruby, Python)или Java.
Java тоже в основных претендентах. В таком облегчённом варианте: сервлеты, Jetty, никаких EJB или application servers... Обязательно в JIT-откомпилированом варианте, чтобы избежать необходимости установки JVM отдельно.
Что же касается скриптовых языков, то все они хороши, особенно Python. Смущает только открытость их кода...
Есть вариант сделать костяк на Java, а бизнес-логику писать на Jython. По предварительным оценкам это в некотором роде пограничный случай: не совсем ясно, стоит ли игра свеч. Казалось бы разработка на Python раза в полтора быстрее, чем на Java, но с другой стороны решение в целом усложняется, увеличивается риск интеграционных проблем, и неясно, как такой "слоёный пирог" будет выглядет в плане производительности.
Здравствуйте, Firstborn, Вы писали:
LV>>Лучше выбрать что-нибудь скриптовое (PHP, Ruby, Python)или Java. F>Java тоже в основных претендентах. В таком облегчённом варианте: сервлеты, Jetty, никаких EJB или application servers... Обязательно в JIT-откомпилированом варианте, чтобы избежать необходимости установки JVM отдельно.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Firstborn, Вы писали:
LV>>>Лучше выбрать что-нибудь скриптовое (PHP, Ruby, Python)или Java. F>>Java тоже в основных претендентах. В таком облегчённом варианте: сервлеты, Jetty, никаких EJB или application servers... Обязательно в JIT-откомпилированом варианте, чтобы избежать необходимости установки JVM отдельно.
L>Это как?
Здравствуйте, Firstborn, Вы писали:
F>>>Java тоже в основных претендентах. В таком облегчённом варианте: сервлеты, Jetty, никаких EJB или application servers... Обязательно в JIT-откомпилированом варианте, чтобы избежать необходимости установки JVM отдельно.
L>>Это как?
F>Так, например.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Firstborn, Вы писали:
F>>А почему нет? Т.е. до пилотирования пока не дошло, но пока всё выглядит реально. Или я что-то упускаю?
L>У меня есть большие сомнения в работоспособности подобных решений.
Что за сомнения? На чём они основаны? На опыте? А поподробнее?
Иначе как-то очень голословно получается и общо.
Здравствуйте, Firstborn, Вы писали:
L>>У меня есть большие сомнения в работоспособности подобных решений.
F>Что за сомнения? На чём они основаны? На опыте? А поподробнее? F>Иначе как-то очень голословно получается и общо.
Тут часто на форуме мелькают сообщения о новых чудодейственных средствах, которые якобы позволяют не устанавливать .Net, да вот только при ближайшем рассмотрении всё это оказывается фуфлом полнейшим.
Не думаю, что в java с этим лучше. Хотя...
Firstborn пишет: > G>А может .NET и SQL Server 2005 ? > Такой вариант несколько смущает необходимостью выкачивания > многомегабайтного фрэймворка, опросы показывают, что более чем у > половины нашей аудитории он не стоит.
И процентов 70 из них просто не знают о том, что он стоит.
> инсталляций обещает быть однопользовательской, т.е. юзер скачал > инсталляцию, проинсталлировал N раз нажав кнопку Next, кликнул на > созданный в результате инсталляции ярлычок на десктопе, открылся броузер > и там наше приложение. Всё, ничего больше юзер не видит и не должен видеть.
Все у вас как-то просто получается... Вы не для Интела пишете??? А то у
них тоже, установил, отрылось окошко браузера, загрузилось приложение и
нихрена не работает.
> При таком сценарии, какие ещё могут быть варианты, кроме сервиса?
Удаленный сервис? То есть приложение у вас, а вебморда у клиента? Аки
гугледокс, к примеру?
> Что же касается более подробного описания задачи — с удовольствием, > намекните только что ещё Вам интересно.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Firstborn, Вы писали:
L>>>У меня есть большие сомнения в работоспособности подобных решений.
F>>Что за сомнения? На чём они основаны? На опыте? А поподробнее? F>>Иначе как-то очень голословно получается и общо.
L>Тут часто на форуме мелькают сообщения о новых чудодейственных средствах, которые якобы позволяют не устанавливать .Net, да вот только при ближайшем рассмотрении всё это оказывается фуфлом полнейшим. L>Не думаю, что в java с этим лучше. Хотя...
А, ну понятно, то есть конкретного практического опыта не имеется. Что ж, тогда его надобно приобресть! Будем, наверное, пилотировать...
Здравствуйте, Firstborn, Вы писали:
L>>Не думаю, что в java с этим лучше. Хотя...
F>А, ну понятно, то есть конкретного практического опыта не имеется. Что ж, тогда его надобно приобресть! Будем, наверное, пилотировать...
Интуиция — великая сила!
Удачи! Если не сложно, отпишитесь сюда по результатам.
Здравствуйте, Ромашка, Вы писали:
Р>Firstborn пишет: >> G>А может .NET и SQL Server 2005 ? >> Такой вариант несколько смущает необходимостью выкачивания >> многомегабайтного фрэймворка, опросы показывают, что более чем у >> половины нашей аудитории он не стоит.
Р>И процентов 70 из них просто не знают о том, что он стоит.
>> При таком сценарии, какие ещё могут быть варианты, кроме сервиса?
Р>Удаленный сервис? То есть приложение у вас, а вебморда у клиента? Аки Р>гугледокс, к примеру?
Отнюдь. Большой процент инсталляций обещает быть вообще однопользовательскими, то есть и "серверный сервис" и броузер, его дёргающий, будут жить на одной машинке.
Р>Насколько конфиденциальные данные, местонахождение целевой аудитории?
Конфиденциальность начинается с определённого уровня конкретики
Могу сказать, что целевая аудитория практически ограничивается Nordic region.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Firstborn, Вы писали:
L>>>Не думаю, что в java с этим лучше. Хотя...
F>>А, ну понятно, то есть конкретного практического опыта не имеется. Что ж, тогда его надобно приобресть! Будем, наверное, пилотировать...
L>Интуиция — великая сила! L>Удачи! Если не сложно, отпишитесь сюда по результатам.
Спасибо!
Постараюсь, только не знаю пока, когда можно будет этих результатов ожидать...
Здравствуйте, Firstborn, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
G>>Поподробнее задачи опишите, а то не очень понятно зачем запуск в виде Windows сервиса и web интерфейс. F>Веб-интерфейс есть требование заказчика. Сервис — логичный вариант для случая, когда видимая часть приложения есть контент в окне броузера; сам "сервер" в это время крутится в виде сервиса и ничем себя не проявляет, ничем не смущает неискушённого юзера. Суть в том, что заметная часть инсталляций обещает быть однопользовательской, т.е. юзер скачал инсталляцию, проинсталлировал N раз нажав кнопку Next, кликнул на созданный в результате инсталляции ярлычок на десктопе, открылся броузер и там наше приложение. Всё, ничего больше юзер не видит и не должен видеть.
F>При таком сценарии, какие ещё могут быть варианты, кроме сервиса?
А при таком сценарии приложение может быть многопользовательским? Или у вас где-то будет еще сервер крутиться? А где будет БД находится?
Вообще непонятно какие задачи должно решать ваше приложение.
Вообще необязательно чтобы само приложение было установлено на компьютере пользователя. Пусть работает где-то на удаленном сервере, а пользователи обращаются через web интерфейс.
Firstborn пишет: > Отнюдь. Большой процент инсталляций обещает быть вообще > однопользовательскими, то есть и "серверный сервис" и броузер, его > дёргающий, будут жить на одной машинке.
Ты не понял. Никаких инсталяций. Клиент открывает браузер, жмет на
кнопочку и вот его приложение. А серверая часть с БД где-нить на
хостинге в новой зеландии.
> Р>Насколько конфиденциальные данные, местонахождение целевой аудитории? > > Конфиденциальность начинается с определённого уровня конкретики
Меня не интересует конкретика. Меня интересует насколько пользователь
считает свои данные конфиденциальными и на каких условиях согласен
доверить их вам.
> Могу сказать, что целевая аудитория практически ограничивается Nordic > region.
Замечательно. Не парьтесь. Делайте интернет-сервис.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, gandjustas, Вы писали:
G>А при таком сценарии приложение может быть многопользовательским?
Идея такова, чтобы приложение можно было бы использовать и в однопользовательском режиме, и в многопользовательском (для небольших групп пользователей), причём для включения последнего просто поставить галочку "разрешить другим коннектиться тоже". Вопрос только в том, откуда "сервер" принимает коннекции — только от localhost, либо отовсюду.
G>Или у вас где-то будет еще сервер крутиться?
Где-то он в любом случае будет крутится. В однопользовательском режиме — на том же компе, за которым трудится единственный юзер.
G>А где будет БД находится?
Там же, где и "сервер". В идеале — embedded, вроде Firebird.
