tygraКстати, а что такое хочет увидеть клиент, что приходится лезть сразу в две а то и три отдельных системы?

Данные он хочет увидеть. Отчеты. Mainframe-ом приведен пример. Я здесь тоже приводил кучу примеров в разных топиках, что хотят видеть клиенты. Посмотрите. Там и университетские системы, и торговля и производство есть. Повторяться думаю не стоит.

tygraВаш обычный толстый клиент ходет напрямую к БД, а мой - через вебсервисы.
Которые не есть СП - они есть "большой драйвер" к СУБД, который только передает данные - не обрабатывает, не считает ничего, только передает.
Система отлично работает и напрямую - в локальной сети.
Но в отличие от использования СП, она не зависит от того, откуда и как к ней пришли - с вебсервера, прямо, из другой СУБД, из эксела... Не важно - бизнес-логика и прочее остается неизменным, потому как оно внутри СУБД.

хм.. Точно как у нас. Только называется это СП , одна из задач которого - большой драйвер к СУБД. Маршрутизирует и передает данные. Считать или нет что-то средствами СП - вопрос реализации в каждом конкретном случае.

tygra
Экзитические примеры однако :)
Но проблема не в том, что СП в этих примерах лучше, а в том, что из-за каких-то соображений существует зоопарк систем, которые не собираются менять на одну. Я только не понял, какие были вначале и какая писалась через СП потом :)
Но если никак вообще нельзя, то оно конечно, что-то надо думать.

Зачем менять то, что прекрасно справляется со своими задачами. Нет комплексов, которые решают все задачи (все конечно можно запрограммировать на одной платформе).

tygraНе, у меня это не СП. Мой стандартный режим работы - напрямую к СУБД. А вебсервисы - это для инетовских клиентов.
А у вас без СП как я понимаю работать нельзя? Или можно?

С БД можно работать напрямую, но штатно в системе работа идет через СП и мы настоятельно рекомендуем именно так и поступать. Но в силу полной открытости платформы каждый конечно волен поступать как хочет. Попыток не было. Помимо маршрутизатора запросов СП еще исполняет и роль управления контентом. Контент устроен специфически. С реализацией его в СУБД делался вариант (чтобы предвосхитить реплику :). Мы все же прежде чем в код что-то положить тщательно исследуем варианты решений ), не прошел. Громоздко, тяжело апгрейдить, вносить изменения, куча лишней работы по преобразованию реляционных данных в объекты контента и т.п. Поэтому выбор был сделан в пользу объектной модели на сервере приложений и как показывает практика - верный. За несколько лет ни одной попытки внести изменения в модель. Простые интерфейсы, элементарные обновления (а-ля замена 1 файла), разнородные приложения в одном интерфейсе, простейший доступ к контенту через интернет, отсутствие какой-либо необходимости администрировать все это. В общем испытания, тесты, практика. Только так я считаю нужно принимать решения.

СисойКстати, это не единственный случай. Потребность в настоящей объектно-ориентированной СУБД (а не надстройках над реляционными) огромна. Но пока промышленного и признанного лидера в этой области так и нет. И только поэтому громоздятся многие СП - ибо обрабатывать объектный контент напрямую на реляционной СУБД - неэффективно (это как сетевые протоколы только через нижние уровни использовать).
В свое время исследовал ObjectStore. Очень интересно. Жаль пропали они. ObjectStore PSE в качестве embeded используют то многие, к примеру OPERA насколько я знаю, а вот про большую СУБД давно не слышно. Скушали.

кому вопрос?

2 tygra
===

- Содержание приложения (меню по-простому). В зависимости от пользователя, его роли, прав доступа и т.п.
- Описание форм ввода
- описание запросов
- описание представлений (отчеты, кубы, графики, орг.диаграммы, шаблоны Excel и т.п.)
- описание вызовов процедур
- описание сценариев
- описание различных прилинкованных модулей, которые включаются в общий контент (скрипты, html, flash, подгружаемые библиотеки классов и т.п.)
- описание источников данных (ole db, odbc, модули прямого доступа к данным)
- описание зависимостей между объектами контента (что из чего запускается, какие параметры и как передаются и т.п.). Например по клику на отчете открыть подробный или открыть форму ввода. Или из html страницы вызвать процедуру, по клику на форме ввода показать флэшку и т.п.
- описание вызовов модулей справочной системы
-...

Все это ориентировано на то, чтобы разрабатывать небольшими блоками и быстро. И изменения соответственно вносить буквально по-горячему. Есть механизмы связывания всех объектов друг с другом внутри одного файла контента или между разными. Есть механизмы подготовки дистрибутивов контента и простые механизмы развертывания. Весь контент автодокументируется. Т.е. это не черный ящик, который непонятно для чего сделан и при отсутствии сделавшего его никто не разберется. Просто реально для решения каждой задачи выбирается наиболее подходящий способ реализации. Что при помощи кейсов делается, что программируется в виде подгружаемых библиотек, часть пишется на скриптах (ObjectPascal, Java) если не реализуемо кейсами, некоторые интерфейсы делаются на html, логика средствами подключаемых СУБД или скриптами. Вся работа делается только в одном месте, на СП. Клиентов вообще никто никогда не трогает. Не ко всем еще и доберешься. Когда консоль подключается к серверу она получает этот контент и соответственно обретает весь его функционал.
Немного длинно и нудно, но надеюсь ответил на Ваш вопрос.

p.s. здесь картинка

2 tygra
===========
Примерно так:

Описание формы лежит в файле контента и редактируется при помощи кейс-редактора. Разработчик определяет для формы источник данных, формирует список полей формы, назначает на них элементы управления, связывает со справочниками, разбивает по закладкам если нужно, назначает формулы и значения по умолчанию, параметры для запуска, выбирает тип представления формы (с обзором, только форму, комбинированный), привязывает справочную систему. Жмет ОК, сохранить. После сохранения в файле контента форма готова к использованию, ее сразу можно запустить и посмотреть что получилось. Запускается при помощи механизмов, которые назваются "ранерами" (runners). Это загружаемые библиотеки, которые могут исполнять различные объекты контента. Любой разработчик может написать свой ранер. Достаточно указать его в списке автозагрузки системы и связать его с типом объекта контента (как в файловой системе назначить типу файла приложение). Ранер строит форму на лету (разрабочики Axapta зовут подобную технологию XMorph). Форму можно компоновать из нескольких форм. Например как делается накладная: отдельно форма шапки, отдельно форма строк. В редакторе они связываются простым выбором из списка и назначением связующих параметров (binding). Таким же образом к форме присоединяются процедуры и дополнительные модули. Основной функционал по работе с формой находится в ранере. Его задача запустить, скомпоновать,обеспечить редактирование, фильрацию, поиск, групповые модификации, запуск связанных документов, сохранение пользовательских настроек, взаимодействие с источникам данных и т.д. Если нужно что-то свое, то к форме цепляется обработчик. Обработчик - файл на ObjectPascal (по умолчанию). В обработчике доступно все что есть на форме и полный доступ к управлению всеми событиями.
Подобным образом выполняется работа со всеми объектами контента информационной системы. Очевидно, что расширение функций - это просто регистрация новых ранеров. На сегодня есть ранеры для формирования интерфейсов форм ввода, исполнения запросов, выполнения скриптов, процедур, сценариев, web-приложений, отчетов, pivot-таблиц, деловой графики, вывода данных в Excel, работы с MacromediaFlash. Причем любой элемент связывается друг с другом. т.е. я могу записать в html или тот же swf сслылку типа <a href = " iconsole://rundocument/?docid="DOC_GUID" ">Текст ссылки</a> и т.п. Все будет исполнено. Таким образом строятся порталы для руководителей, которым скучно бродить по меню.

Здесь картинки

Конечно подобное реализовать без единого связующего звена, которым является сервер приложений не представляется возможным. А вычисления на нем стараемся делать в крайнем случае, если средствами СУБД затруднительно или нужно разнести.

спасибо tygra.
Думаю очередная реинкарнация темы себя исчерпала. Всем успехов на всех уровнях.

зы. + 1 сообщение.