v_daniloviscrafmесли интересует архитектура, напишите в личку, отвечу на все Ваши вопросы. Здесь общаться невозможно.

Архитектура не интересует. И не потому, что она неинтересна, а потому что она НИ ЧЕМ не отличается от других.
если бы она ничем не отличалась, то я бы ей не занимался, а взял бы что-то готовое. Посмотрите на сайте раздел с описанием архитектуры. Буду очень признателен, если дадите ссылку на такую-же архитектуру в уже существующих системах. Сейчас правда достаточно СОА систем, но как всегда - дьявол в деталях.
Насчет выбора СУБД.. Что Вас все таки смущает во фразе "выбрана любая СУБД"? Кто ORACLE выбирает, кому милей FB или PostgreSQL , а кто-то поклонник MS SQL... В чем проблема? Берите любимую СУБД и стройте свою систему, у сервера приложений есть интерфейсы ко всем, что на слуху. Скорее всего Вы действительно не совсем правильно поняли суть этой системы. Повторять не буду, Егоров Александр достаточно корректно ее растолковал, респект ему.

v_daniloviscrafm
обзорно так:
формы ввода - 264
запросы - 122
отчеты -142
процедуры - 144
сценарии - 34

Количество человек?

этот конкретно проект - 1. Я сам его делал.

v_daniloviscrafm
механизмы взаимодействия окон (и других объектов) между собой - задача платформы
т.е. это уже существовало? как? если окон еще не было, как и процедур.
как можно в клиенте обратиться к другому окну/процедуре не зная его имени / id?
или же все-таки разработанные окна/процедуры регистрируются где-то в таблицах и есть требования к их структуре?
как в клиенте происходит определение, что открыть надо такое-то окно?

Все визуально. Примерно так . Все "объекты" в репозитории сервера приложений, в нем они и регистрируются.

v_daniloviscrafmСреднее звено общается с СУБД, клиент общается со средним звеном.
Я знаю для чего нужен сервер приложений. Вы мне скажите, кроме функции прослойки отвечает он еще за что-то?
Безопасность, бизнес-логика ( если требуется ), управление контентом...

v_daniloviscrafmЕгоров Александр достаточно корректно ее растолковал, респект ему.
Ни Вы, ни упомянутый Александр так и не ответили, как работает логика приложения. Не путать с бизнес-логикой.
посмотрите ссылку с роликом. Там хорошо видно как работает логика приложения. В первом ролике показано как работает логика компоновки сервисов, как они запускаются, как передаются данные между сервисами и т.п. Здесь, например, как устроена отчетная система . Или какого ответа Вы ждете, уточните?

nicktcheriscrafm
...
Все визуально. Примерно так. Все "объекты" в репозитории сервера приложений, в нем они и регистрируются.
...
Безопасность, бизнес-логика ( если требуется ), управление контентом...

Чем это всё отличается от 1С принципиально ?
хм.. даже не знаю как отвечать на такой вопрос. Принципиально, на выходе получается конфигурация, которая исполняется "виртуальной машиной" платформы. На этом сходство заканчивается. Странный вопрос.

Егоров АлександрНасчет возможности транслировать платформой бизнес-логику в конкретную СУБД тоже инетерсно.
Александр, ничего она самостоятельно не транслирует, кроме автоматических запросов на чтение, вставку, обновление данных на основании настроек формы ввода, к примеру. И то, если разработчик не поставит флажок запрета автоматической корректировки.
А так,.. если на другом конце
FB - execute procedure applyprogress(:TagID, :St);
ORACLE -
begin
demo.applyprogress(:TagID, :St)
end;
MS SQL - exec applyprogress(:TagID, :St);

и т.д. Т.е. Вы сами принимаете решение. Искра предоставит возможность оформить Ваше решение в виде сервиса и использовать его там, где это необходимо, реализовал единожды.

v_danilovну а теперь математика:
в месяце 24 раб.дня по 8 часов, итого 120 часов

Делим приведенное выше и получаем, что в час Вы создавали:
2 формы
1 запрос
1 отчет
1 процедуру
чуть-чуть сценария

Разве это реально?

Могу предположить...

не нужно предполагать. Даже вот эта фраза '264 формы предварительно были уже нарисованы (в Ворде)', говорит о том, что вы смотрите на весь процесс создания системы с позиций какой-то другой платформы и других методов, к которым Вы привыкли. Ничего этого нет. Где Вы на ролике увидели необходимость предварительной прорисовки чего либо интересно.. Насчет того, что за час... Бывало и 10-к форм, а можно один отчет пару часов рисовать.

v_danilovКаковы трудозатраты?
3 месяца, если все сложить.


v_daniloviscrafm
Все визуально. Примерно так . Все "объекты" в репозитории сервера приложений, в нем они и регистрируются.
Что есть "репозиторий"? Файл, реестр, таблицы? Где хранится?
файл, типа объектной БД. Храниться на сервере приложений. Клиент получает его состав в соответствии с полномочиями.

v_daniloviscrafmБезопасность, бизнес-логика, управление контентом...
Что означает "безопасность", "бизнес-логика"? как? Это написанный и скомпилированный код? или нет?
это означает, что сервер приложений обеспечивает доступ к репозиторию в соответствии с настроенными полномочиями путем авторизации или + ролевого доступа. Бизнес логика может быть вынесена на сервер приложений в откомпилированном виде или в форме DelphiScript, VBS, JavaScript, PERL... Я, лично, предпочитаю процедуры БЛ размещать в СУБД. Насколько я знаю, большинство разработчиков тоже.

p.s. Сценарий - это скомонованные в единый сервис другие сервисы, которые запускаются в определеной последовательности с заданными параметрами...

v_daniloviscrafm
посмотрите ссылку с роликом. Там хорошо видно как работает логика приложения. В первом ролике показано как работает логика компоновки сервисов, как они запускаются, как передаются данные между сервисами и т.п. Здесь, например, как устроена отчетная система . Или какого ответа Вы ждете, уточните?
Там видно только КАК можно мышкой зарегистрировать "новый" функционал. Меня же интересует, ЧТО происходит при регистрации нового функционала. Куда попадает введенная пользователем информация?
объекты, созданные разработчиком, попадают в репозиторий на сервере приложений. Информация введенная пользователем, естественно, в то место, которое определил разработчик. Пользователя это не интересует. К примеру публикуется документ в системе документооборота. Пользователь вводит данные. Далее по маршруту данные, к примеру, оказываются на другом конце страны и совершенно в другой СУБД. Разработчик прекрасно знает куда он пишет информацию, введенную пользователем и каким образом ее обрабатывает.

v_danilovВсе правильно)
Поэтому в супер-архитектуру я давно уже не верю)
и зря. За счет архитектуры издержки на создание системы можно снизить на порядок.