биллингист GeenS
Абсолютно верно! Темой больших систем владею не очень...Темой энергосбыта - очень владею! А насчет амбиций - упаси Бог идти на такие масштабы! Пахнет катастрофой...Но запас надо ведь иметь? или нет?

Добрый день. Ваша идея вполне понятна.
Отвлекаясь от технической стороны вопроса, если вы сделаете такую систему - заказчики есть на услуги ее аренды? Это скорее маркетинговый вопрос уже.
Про SPL тут правильно писали, они я думаю захватят большую часть рынка в биллинге коммунальных платежей. Хотя! Это вопрос политический более, а не технический.
Вот например одну известную импортную систему биллинга в одном крупнейшем операторе связи за огромные бабки начали внедрять - "сверху". Так же сейчас и похоже завершили. Тогда как теперь внедряют - другие системы, уже отечественные.
Так что если а) сделаете что-то удобоваримое хоть немного и главное красиво выглядящее и б) это систему будет кто-то продвигать в играх на весьма высоких уровнях руководств - то почему бы вам не занять эту нишу... Ну а не получится - уйдете большим менеджером в SPL...
С уважением.

Доброе утро очень рад услышать мнение человека, который понимает все нюансы вопроса...Кто в теме.

Наверное пора подводить черту. Во-первых на основании высказываний участников, собственных
изысканий, советов друзей сформировалось у меня вполне устойчивое мнение. Во-вторых, врядли
что нибудь кардинально новое будет сообщено в дискуссии.

Итак. Абстрагируемся от всяческих "...звенок". Не суть важно сколько звеньев, важно как
устроена архитектура системы. У меня сформировались вполне четкие постулаты. Выскажу.

Бизнес логика.
Все таки место ей на сервере БД. Мой ЛИЧНЫЙ опыт мне ЛИЧНО доказывает, что бизнес логика
написанная при помощи простых хранимых процедур на декларативном SQL (коллеги, прошу обратить внимание, декларативность языка - есть выдающееся его достоинство, это вам подтвердят любые эксперты в области компьютерных языков), при насыщении системы продуманным и богатым набором пользовательских функций (почему все о них забыли? это же мощнейщее средство - мне они очень и очень помогали!) - весьма эффективна, по скорости непревзойденна. Что надо-то на самом деле? ТЩАТЕЛЬНЕЙШЕЕ ПРОЕКТИРОВАНИЕ БД - и все.

Разбивка таблиц по подсистемам, проектирование процедур как API системы, смоделировав поведение, соглашение по именам (ОЧЕНЬ ВАЖНО), префиксы имен объектов системы (ОЧЕНЬ ВАЖНО) - одним словом "Arbeit, Arbeit und Disciplin". Я не встречал в своей практике случаев когда невозможно было обойтись одним T-SQL. Мне могут заметить, что я не делал больших систем. Да не делал. Но расчеты и обработки - такие вывернутые приходилось делать - мама не горюй! И ничего. Очень даже работают. В той же энергетике. Так это T-SQL! А PL/SQL еще более наворочен из того что я знаю. Даже наверное излишне. А сколько еще инструментов имеют современные СУБД? Дискуссия тоже это подтверждает.

Сервер приложений.
Необходимость сервера приложений для меня была не очевидна, сейчас еще более не очевидна.
Просто нужен инструмент: А) дающий возможность удаленного доступа к БД и бизнес логике
расположенной на БД; Б) регулирующий нагрузку на стадии удаленного доступа; В) обеспечивающий некоторую достаточную степень безопасности для сервера БД, с тем чтобы (простите мне мой французский!) не выставлять его (сервер БД) голой ж..ой в интернет...Это и есть сервер приложений? если да, то он таки нужен...

Об интерфейсе.
Все таки web. Я тут встретил старого приятеля он большой спец по web и .NET работал в Москве, потом вернулся - не нравится потогонка, лодырь (но при этом светлая голова). Так он мне показал свои фокусы на AJAX - весьма развитые штучки можно сделать, если грамотно спроектировать, вполне и очень даже юзабельно!

О платформе
Желательно MS. Однако если встанут непреодолимые препятствия - можно иные, но в любом случае, даже тот же JBoss не будет содержать в себе БЛ. Ни за что...

О простоте
Коллеги которые строят мудреные системы где часть БЛ на сервере, часть на СП, строят сложную
модель объектов, выстраивает маппирование ХП на объекты...придумывают внутренний язык системы - ох, от лукавого это все... Коллеги, обращаюсь к вам - простота, сама по себе достоинство! если мы хотим получить новую функциональность посредством неадекватного усложнения системы тогда ну ее на х... эту новую функциональность. Это значит что надо остановиться и подумать: о природе новой функциональности (а откуда она упала на нас?), о способах приобрести ее (если она нужна) иным путем. И скорее всего решение будет найдено.

Я тут промоделировал одну схему, которую мне предлагал некий человек при которой в БД строиться только минимальная структура - хранилище объектов, а бизнес логика поддерживается красивой и развитой объектной моделью вне БД. И что? На первый взгляд все красиво. Начал проектировать инструмент манипуляции объектами в модели (добавление новых классов и объектов, изменение атрибутов etc.). Очень быстро выяснилось, что потребуется генерация сложного динамического SQL встроенного в модель, умного, хитро вывернутого, ЧРЕВАТОГО НЕОЧЕВИДНЫМИ ОШИБКАМИ - и все для чего? для того, чтобы записывать результаты работы с этой объектной красотой в БД. Ради этого столько крови? фи...

Вытягивать данные из такой структуры БД в отчеты тоже вылилось в какой то абсурд. Сначала надо вытянуть запрашиваемые объекты (до этого надо написать инструмент создания запросов для данной объектной модели - еще один паровой велосипед!), потом средствами языка для этого совершенно не приспособленного опросить объекты (разве это сравниться с элегантной лаконичной красотой SQL ?) выложить результат в некую структуру: либо XML, либо еще что нибудь свое...Ну и на хрена все это?

ИМХО этот путь ведет в ад. Пусть лучше я буду ретроградом и буду масштабировать аппаратурой БД, но в этот кошмар с написанием ОО-моделей я втягиваться не хочу.