Здравствуйте, DMVB, Вы писали:

DMV>Теперь Axapta в моду входит. Так может лучше эту нишу занять? Сделать добротную конфигурацию и продавать.Народ об Axapta вроде неплохо отзывается.

Ты думаешь там нет "добротной конфигурации"? А для специфики — отраслевые решения.

Здравствуйте, mvg_first, Вы писали:

MF>Мало ли чем это попахивает — что делать? Пусть будет .Net какая разница.

Очень большая

MF>на VC тоже можно писать под .net

Можно, но не нужно. Тем более что не на VC, а на МС++.

MF>Предлагайте конкретные шаги которыме мне нужно сделать что бы начать (пусть даже и имея двух специалистов по 1С)

Купить книжку Гамма и Ко "Паттерны ОО программирования" и внимательнейшим образом ее прочитать. Далее все таки определиться — .NET или Java. Если нет необходимости работы на мейнфреймах под юнихами то наверное .net предпочтительнее. Далее выбрать предварительную схему твоей системы.
0) Определиться — какая тебе нужна от сервера функциональность. Т.е. от простейших триггеров и ХП вроде MIDAS до полномасштабного фреймворка вроде решений J2EE.
1) клиент толстый, тонкий, сверхтонкий, веб браузер.
2) Хранилище — РСУБД или ООСУБД.
3) Представление данных внутри сервера — курсоры, xml, объектное.
4) Выбрать механизм меппинга (зависит от п.3).
5) Местоположение, формат хранения и язык бизнес-приложений
6) Схема идентификации и аутентификации
7) Схема балансировки
8) Жизненный цикл объектов в БД. Их возможные типы — стейтлес, стейтфул, энтити.
9) Механизм контроля версий.
10) Алгоритмы кеширования.
11) Конфигурирование.
12) Механизмы взаимодействия между клиентом и сервером. В случае .NET это прежде всего Remoting и веб сервисы. Для джавы это RMI.

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

PS: У нас тут на rsdn.ru народ собирается, да все никак не соберется писать свой сервер приложений под дотнет. Так может тебе лучше их потерзать и самому принять деятельное участие в этом проекте?

PPS: На Java есть много готовых серверов приложений — как очень мощных коммерческих, так и бесплатных. Так может тебе не писать свою среду исполнения а воспользоваться готовым сервером? Для начала можешь посмотреть Resin-EJB (www.caucho.com) и Orion Application Server (http://www.orionserver.com/). Оба довольно простые, имеют приемлемую документацию и бесплатны для некоммерческой разработки. Когда понадобится тяжелое решение то есть BEA Web Logic, Borland Application Server.
Для дотнета готового сервера приложений нет, есть возможность интеграции классов .NET в среду СОМ+. То есть тот самый DCOM о котором ты в первом посте поминал.

K>Ты думаешь там нет "добротной конфигурации"? А для специфики — отраслевые решения.
Я думаю что есть, просто хотел сказать, что выгоднее и проще найти свою нишу на уже сформировавшемся рынке, чем пытаться осчастливить мир. Дешевле обойдется.

Здравствуйте, Аноним, Вы писали:

А>уважаю отважных людей. серьезно. без сарказма.
А>если так, тогда что уж вам какой-то комбинатик автоматизировать. если будет написано хорошее ядро, соответствующий макетинг, глядишь с 1С, сапом, аксаптой.. сможете конкурировать. иначе, имхо, овчинка выделки не стоит. тратить лет 5 жизни ради написания движка, который будет востребован 2-3 клиентами, опять же имхо, не серьезно.
А>украсть — так миллион...

Вот когда напишу ядро, тогда и буду губы пялить Да маркетинг искать, а так пока только мысли Да попытки найти соответствующую помощь, в этом деле.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, DarkGray, Вы писали:

DG>>Если бы ты сразу бы выбрал бы .Net, то и разговор бы пошел в более конструктивном русле.

AVK>Ну или хотя бы вынес вопрос на обсуждение. А то что такое .NET я не знаю, что такое Java не знаю, что такое vC не знаю, даже что такое ООП не полностью представляю, но писать буду исключительно на VC. Одно из двух — либо у него логика совсем не к черту, либо все таки какие то причины есть, но он ими делиться не хочет.

AVK>
Причина одна — недостаток времени на обучение. Т.е. предполагается что будем обучаться находу по мере возможности, так сказать на рабочем проекте. А вот про ООП зря Вы так, достаточно долго его изучаю, правда это если об ООП как об объектно ориентированном программировании, если дело идет о проектировании то тут Вы правы изучать мне его еще и ищучать.

Здравствуйте, mvg_first, Вы писали:

MF>Причина одна — недостаток времени на обучение.

Поэтому выбираем самый сложный для изучения язык? По прежнему не вижу логики.

MF>если дело идет о проектировании то тут Вы правы изучать мне его еще и ищучать.

Потому и посоветовал тебе книжку про паттерны.

Здравствуйте, AndrewVK, Вы писали:

AVK>Можно, но не нужно. Тем более что не на VC, а на МС++.



AVK>Купить книжку Гамма и Ко "Паттерны ОО программирования" и внимательнейшим образом ее прочитать. Далее все таки определиться — .NET или Java. Если нет необходимости работы на мейнфреймах под юнихами то наверное .net предпочтительнее. Далее выбрать предварительную схему твоей системы.

Книжку эту я купить не могу. Говорят ее выпускать перестали, а в электронном виде нету (на русском)

Ладно, будем считать Вы меня уломали Я определился, буду писать под нет


AVK>0) Определиться — какая тебе нужна от сервера функциональность. Т.е. от простейших триггеров и ХП вроде MIDAS до полномасштабного фреймворка вроде решений J2EE.
Ой господи даже и не знаю Вообщем то мне нужен AppServer на котором будет крутится контроль прав и бизнес логика, может это и Хранимые процедуры и триггеры, но мне кажется что это чуть чуть боьлше. К сожалению я не изучал концепций J2EE поэтому не могу сказать нужен ли мне его фреймворк . Если вкратце опишете перспективы его, и это меня заинтересует. То изучу детальнее.

AVK>1) клиент толстый, тонкий, сверхтонкий, веб браузер.
Предполагается средней тонкости. Т.е. банальные запросы на выполнение операции и вывод данных на экран, вся логика — дело сервера.
AVK>2) Хранилище — РСУБД или ООСУБД.
РСУБД
AVK>3) Представление данных внутри сервера — курсоры, xml, объектное.
Какого сервера? Разрабатываемого мной? — все должно быть в виде объектов.

AVK>4) Выбрать механизм меппинга (зависит от п.3).
Что такое меппинг? Не встречал этого понятия в совей практике? Объясните в двух словах не более общий смысл.

AVK>5) Местоположение, формат хранения и язык бизнес-приложений
Бизнес-логике — на сервере приложений (средний уровень), формат хранения??? (непонимаю) если имеется ввиду каким образом будут они подключаться к серверу, то планирую расширяемые модули, плагины (скорее всего ДЛЛ).
AVK>6) Схема идентификации и аутентификации
В этом месте много открытых вопросов. Я их планировал задавать когда приступлю к реализации. Приблизительно так: данные о пользователях на сервере, у каждого есть права на выполнение операций бизнес-логики а также права на доступ к конкретным объектам бизнес логики и соответсвенно суммирование прав на выполнение операции с правами на доступ к конкретному объекту.

AVK>7) Схема балансировки
Не значю что это Надеюсь пока незнаю.

AVK>8) Жизненный цикл объектов в БД. Их возможные типы — стейтлес, стейтфул, энтити. (пока тоже слабо понимаю очем говорят эти три термина) Но думаю у разных объектов будут разные жизненные циклы, как можно говорить об этом заранее?

AVK>9) Механизм контроля версий.
Собираюсь просить помощи в этом вопросе у общественности.

AVK>10) Алгоритмы кеширования.
необдумывал

AVK>11) Конфигурирование.
Конфигурирование планировалось — параметрическое. т.е. первые версии продукта будут таки сильно стеснены в вопросах конфигурирования. Т.е. под каждую автоматизируемую задачу планировалось написание дополнительных модулей(как для серверов так и для клиентов)

AVK>12) Механизмы взаимодействия между клиентом и сервером. В случае .NET это прежде всего Remoting и веб сервисы. Для джавы это RMI.
Вопрос остается открытым, с моей колоколни — самый главный вопрос- выяснить как передавать наборы записей (например табличную часть накладной) от сервера клиенту???

AVK>Это самые самые базовые вопросы, которые должны быть решены прежде чем ты напишешь хоть строчку кода.
Я надеюсь Вы мне поможете пролить свет на эти вопросы, внести ясность так сказать. Ибо многие из этих вопросов тяжело разрешить самостоятельно в сжатые сроки (ибо как распылены они по литературе достоточно широко)


AVK>PS: У нас тут на rsdn.ru народ собирается, да все никак не соберется писать свой сервер приложений под дотнет. Так может тебе лучше их потерзать и самому принять деятельное участие в этом проекте?
Можно ссылку почитать посмотреть?


AVK>PPS: На Java есть много готовых серверов приложений — как очень мощных коммерческих, так и бесплатных. Так может тебе не писать свою среду исполнения а воспользоваться готовым сервером? Для начала можешь посмотреть Resin-EJB (www.caucho.com) и Orion Application Server (http://www.orionserver.com/). Оба довольно простые, имеют приемлемую документацию и бесплатны для некоммерческой разработки. Когда понадобится тяжелое решение то есть BEA Web Logic, Borland Application Server.


AVK>Для дотнета готового сервера приложений нет, есть возможность интеграции классов .NET в среду СОМ+. То есть тот самый DCOM о котором ты в первом посте поминал.
Скорее всего буду именно это и использовать. Посему хотелось бы примеров (может банальных, но откражающих суть этого вопроса) Может даже и на MC++

Здравствуйте, DMVB, Вы писали:

DMV>Ага, только еще сначала лопату сделать

Зато можно ТАКУЮ лопату забабахать! С гидроусилителем, автоотбрасывателем земли, ортопедической ручкой и управляемую мозговыми импульсами!

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, mvg_first, Вы писали:

MF>>Причина одна — недостаток времени на обучение.

AVK>Поэтому выбираем самый сложный для изучения язык? По прежнему не вижу логики.

MF>>если дело идет о проектировании то тут Вы правы изучать мне его еще и ищучать.

AVK>Потому и посоветовал тебе книжку про паттерны.

Проблема ведь не в изучении языка VC, синтаксис и правила работы я знаю писал несколько игрушечных программок, проблема в интеграции и использовании технологий того же .NET с конкретным языком. Надеюсь Вы понимаете что я пытаюсь сказать на протяжении всего этого топика. Скажем так информационный голод по интеграции новых технологий в прикладные приложения (и не просто так наляпаять абы было, а с толком) вот именно это меня больше всего и напрягает. Может быть даже по завершению этого терда, я смогу сформировать более правильный вопрос, надеюсь Вы в этом мне поможете.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, DMVB, Вы писали:

dad>>>надысь было ДР Боба Марлей.. Сие послание очень в тему... Думаю некоторые меня поймут (гыгыгыгы)
DMV>>
А>да уж

Здравствуйте, mvg_first, Вы писали:

MF>Проблема ведь не в изучении языка VC, синтаксис и правила работы я знаю писал несколько игрушечных программок, проблема в интеграции и использовании технологий того же .NET с конкретным языком. Надеюсь Вы понимаете что я пытаюсь сказать на протяжении всего этого топика. Скажем так информационный голод по интеграции новых технологий в прикладные приложения (и не просто так наляпаять абы было, а с толком) вот именно это меня больше всего и напрягает. Может быть даже по завершению этого терда, я смогу сформировать более правильный вопрос, надеюсь Вы в этом мне поможете.

Хоть один вразумительный довод. Но, имхо, ваше мнение ошибочно, как раз все наоборот.

Здравствуйте, AndrewVK, Вы писали:

AVK>PPS: На Java есть много готовых серверов приложений — как очень мощных коммерческих, так и бесплатных. Так может тебе не писать свою среду исполнения а воспользоваться готовым сервером? Для начала можешь посмотреть Resin-EJB (www.caucho.com) и Orion Application Server (http://www.orionserver.com/). Оба довольно простые, имеют приемлемую документацию и бесплатны для некоммерческой разработки. Когда понадобится тяжелое решение то есть BEA Web Logic, Borland Application Server.
Я бы еще http://www.jboss.org/ упомянул.

Здравствуйте, Sinclair, Вы писали:

S>Я бы еще http://www.jboss.org/ упомянул.

Глючен он, как хороший косяк.

Здравствуйте, AndrewVK, Вы писали:

AVK>Глючен он, как хороший косяк.
Некжто до сих пор? Мы с ними имели дело ажно в 2000м. Хорошая была заявка на успех. И цена подходяшшая.

Здравствуйте, mvg_first, Вы писали:

MF>Ой господи даже и не знаю Вообщем то мне нужен AppServer на котором будет крутится контроль прав и бизнес логика, может это и Хранимые процедуры и триггеры, но мне кажется что это чуть чуть боьлше. К сожалению я не изучал концепций J2EE поэтому не могу сказать нужен ли мне его фреймворк . Если вкратце опишете перспективы его, и это меня заинтересует. То изучу детальнее.

Центральное звено J2EE это EJB-сервер — среда исполнения для enterprise java beans, т.е. бизнес-компонент. Бины бывают 2 видов: сессионные(session beans) и сущности(entity beans). Сессионные бины в свою очередь подразделяются на стейтлесс(не хранящие состояние, по сути просто набор процедур) и стейтфул(хранящие состояние). Стейтлесс бины самые быстрые, по сути они общие на всех клиентов, но в каждый конкретный момент этим бином пользуется только один клиент, т.е. многопоточного исполнения нет. Для параллельного исполнения кода создается пул таких бинов. Стейтфул бины создаются для каждого клиента свои и живут в течение его сессии.
Энтити бины это компоненты, отражающие персистентные объекты, срок жизни которых превышает срок жизни самого процесса сервера. Обычно их состояние хранится в РСУБД. Они в свою очередь тоже бывают двух видов — BMP (bean managed persistence) и CMP(container managed persistence). Первые должны содержать два специальных метода — Load и Save, в которых ты сам должен загрузить или сохранить объект где тебе необходимо. Во вторых код этих методов генерируется автоматически. Т.е. фактически ты просто описываешь набор свойств компонента, а хранение в БД целиком ложится на контейнер.
Кроме того в EJB-сервере как правило есть куча дополнительных сервисов. Прежде всего сервис взаимодействия с клиентом. Далее обязательно сервер имен. Очень часто веб-сервер с servlets&JSP engine. Очень часто бывает менеджер соединений с БД. Аутентификация как правило накручивается сверху на основе JAAS, хотя в jboss по моему она уже встроена.

AVK>>1) клиент толстый, тонкий, сверхтонкий, веб браузер.
MF>Предполагается средней тонкости. Т.е. банальные запросы на выполнение операции и вывод данных на экран, вся логика — дело сервера.

Это уже тонкий клиент.

AVK>>4) Выбрать механизм меппинга (зависит от п.3).
MF>Что такое меппинг? Не встречал этого понятия в совей практике? Объясните в двух словах не более общий смысл.

У как все запущено. В РСУБД данные храняться ввиде плоских таблиц, связанных отношениями в иерархическую структуру. Объекты в программе представляют собой структуру сетевую. Преобразование модели данных хранилища в модель данных сервера называется mapping. Судя по твоему выбору тебе нужен OO<->Relational mapping. Создание такого меппинга так чтобы он был не более чем на порядок медленнее обычного обращения на групповых операциях нетривиальная задача в общем то.

MF>Бизнес-логике — на сервере приложений (средний уровень), формат хранения??? (непонимаю) если имеется ввиду каким образом будут они подключаться к серверу, то планирую расширяемые модули, плагины (скорее всего ДЛЛ).

Ага, тут ты похоже даже не думал. Подумай о том что есть технологии динамической компиляции, т.е. приложение можно распространять прямо в исходных текстах, есть xml. Стоит задуматься и о механизме деплоймента. В случае СОМ+ деплоймент превращается в адову работу.

AVK>>6) Схема идентификации и аутентификации
MF>В этом месте много открытых вопросов. Я их планировал задавать когда приступлю к реализации.

Низзя. Это очень часто встречающаяся ошибка. Пока ты не продумаешь базовые вопросы нельзя писать ни одной строчки кода, иначе потом придется все переписывать.

MF> Приблизительно так: данные о пользователях на сервере, у каждого есть права на выполнение операций бизнес-логики а также права на доступ к конкретным объектам бизнес логики и соответсвенно суммирование прав на выполнение операции с правами на доступ к конкретному объекту.

Как эти права задавать? Где хранить? Как обеспечивать безопасность обмена между сервером и клиентом? Какая политика назначения прав — по уровню, по группе, по индивидуальному пользователю или смешанная. Каким образом организованы объекты доступа — линейно, иерархически, сетевая структура или какая то их смесь?

AVK>>7) Схема балансировки
MF>Не значю что это Надеюсь пока незнаю.

Схема распределения нагрузки на несколько серверов. Хорошие сервера приложений как правило умеют работать в составе кластера серверов, динамически распределяя между ними нагрузку, а иногда еще и бессбойная (ну или хотя бы со сбоем только у его клиентов) изоляция отказавшего сервера с непрерывностью функционирования кластера в целом.

MF>(пока тоже слабо понимаю очем говорят эти три термина) Но думаю у разных объектов будут разные жизненные циклы, как можно говорить об этом заранее?

Посмотри описание EJB — идея то она везде общая. А планировать жизненные циклы нужно обязательно, это одна из основных характеристик сервера приложений.

AVK>>9) Механизм контроля версий.
MF>Собираюсь просить помощи в этом вопросе у общественности.

То есть тоже не думал. Плохо.

AVK>>10) Алгоритмы кеширования.
MF>необдумывал

Без этого производительность твоего сервера будет плачевной. А если еще и OO-Relational меппинг наличествует, то производительность без кеша объектов будет просто никакая.

AVK>>11) Конфигурирование.
MF>Конфигурирование планировалось — параметрическое. т.е. первые версии продукта будут таки сильно стеснены в вопросах конфигурирования. Т.е. под каждую автоматизируемую задачу планировалось написание дополнительных модулей(как для серверов так и для клиентов)

И тем не менее на дотнете можно реализовать полностью автоматическую систему конфигурирования произвольных модулей. Прообраз такой системы можно поглядеть в янусе ака RSDN@Home.
В джаве на конфигурирование есть стандарт — JMX.

AVK>>12) Механизмы взаимодействия между клиентом и сервером. В случае .NET это прежде всего Remoting и веб сервисы. Для джавы это RMI.
MF>Вопрос остается открытым, с моей колоколни — самый главный вопрос- выяснить как передавать наборы записей (например табличную часть накладной) от сервера клиенту???

Ну я же сказал — ремоутинг или веб-сервисы. Первый много гибче, второй позволит писать клиентов на С++, Дельфи, старом VB, но возможности у него куда как более скудные.

Да, совсем забыл — надо еще продумать механизм транзакций, в том числе и распределенных.

MF>Я надеюсь Вы мне поможете пролить свет на эти вопросы, внести ясность так сказать. Ибо многие из этих вопросов тяжело разрешить самостоятельно в сжатые сроки (ибо как распылены они по литературе достоточно широко)

В сжатые сроки это сколько конкретно?

AVK>>PS: У нас тут на rsdn.ru народ собирается, да все никак не соберется писать свой сервер приложений под дотнет. Так может тебе лучше их потерзать и самому принять деятельное участие в этом проекте?
MF>Можно ссылку почитать посмотреть?

А нету пока даже ссылки. Так, треп пока один в форумах. Все ждут когда кто нибудь скажет — делаем. Но как минимум трое уже согласны
(Пользуясь случаем, передаю привет Владу, Синклеру и IT )

AVK>>Для дотнета готового сервера приложений нет, есть возможность интеграции классов .NET в среду СОМ+. То есть тот самый DCOM о котором ты в первом посте поминал.
MF>Скорее всего буду именно это и использовать. Посему хотелось бы примеров (может банальных, но откражающих суть этого вопроса) Может даже и на MC++

Смотри в форуме по дотнету. Но там есть подводные камни. Прежде всего очень кривой деплоймент и кое какие неясности с событиями и колбеками.

Здравствуйте, Sinclair, Вы писали:

AVK>>Глючен он, как хороший косяк.
S>Некжто до сих пор?

Когда я его последний раз видел, а это было месяцев 10 назад, был еще весма глюкав. Текущее состояние не знаю.

S> Мы с ними имели дело ажно в 2000м. Хорошая была заявка на успех. И цена подходяшшая.

Ну цена то да Но у нас, блин, Россия. Так что можно и резин с орионом ставить, никто следить не будет.

Здравствуйте, kreek, Вы писали:

K>Здравствуйте, mvg_first, Вы писали:

MF>>Проблема ведь не в изучении языка VC, синтаксис и правила работы я знаю писал несколько игрушечных программок, проблема в интеграции и использовании технологий того же .NET с конкретным языком. Надеюсь Вы понимаете что я пытаюсь сказать на протяжении всего этого топика. Скажем так информационный голод по интеграции новых технологий в прикладные приложения (и не просто так наляпаять абы было, а с толком) вот именно это меня больше всего и напрягает. Может быть даже по завершению этого терда, я смогу сформировать более правильный вопрос, надеюсь Вы в этом мне поможете.

K>Хоть один вразумительный довод. Но, имхо, ваше мнение ошибочно, как раз все наоборот.

У меня этих мнений как грязи. Какое из них ошибочно? И что наоборот?

Здравствуйте, AndrewVK, Вы писали:


AVK>Центральное звено J2EE это EJB-сервер — среда исполнения для enterprise java beans, т.е. бизнес-компонент. Бины бывают 2 видов: сессионные(session beans) и сущности(entity beans). Сессионные бины в свою очередь подразделяются на стейтлесс(не хранящие состояние, по сути просто набор процедур) и стейтфул(хранящие состояние). Стейтлесс бины самые быстрые, по сути они общие на всех клиентов, но в каждый конкретный момент этим бином пользуется только один клиент, т.е. многопоточного исполнения нет. Для параллельного исполнения кода создается пул таких бинов. Стейтфул бины создаются для каждого клиента свои и живут в течение его сессии.
AVK>Энтити бины это компоненты, отражающие персистентные объекты, срок жизни которых превышает срок жизни самого процесса сервера. Обычно их состояние хранится в РСУБД. Они в свою очередь тоже бывают двух видов — BMP (bean managed persistence) и CMP(container managed persistence). Первые должны содержать два специальных метода — Load и Save, в которых ты сам должен загрузить или сохранить объект где тебе необходимо. Во вторых код этих методов генерируется автоматически. Т.е. фактически ты просто описываешь набор свойств компонента, а хранение в БД целиком ложится на контейнер.
AVK>Кроме того в EJB-сервере как правило есть куча дополнительных сервисов. Прежде всего сервис взаимодействия с клиентом. Далее обязательно сервер имен. Очень часто веб-сервер с servlets&JSP engine. Очень часто бывает менеджер соединений с БД. Аутентификация как правило накручивается сверху на основе JAAS, хотя в jboss по моему она уже встроена.

Спасибо за разъяснение. Но если Вы будете так добры что сможете указать мне литературу желательно в электронном виде, как это приложение сделать Я с удовольствием возьмусь изучать джаву и закину все остальные потуги. А надо мне для этого всего ничего, какой нибудь пошаговый туториал, в котором расписано создание серверной и клиентской части. Что бы я собственными руками пропустил это все через спинной мозг и осознал, а так пока только красивые слова, которым я поражаюсь (как все просто ). Но пощупать не знаю как. Один из указанных Вами примеров я скачал, и даже распаковал А что делать дальше как запустить пощупать — незнаю. И где брать джаву к сожалению тоже

AVK>>>1) клиент толстый, тонкий, сверхтонкий, веб браузер.
MF>>Предполагается средней тонкости. Т.е. банальные запросы на выполнение операции и вывод данных на экран, вся логика — дело сервера.

AVK>Это уже тонкий клиент.
Да я вообщем это и понимаю .

AVK>>>4) Выбрать механизм меппинга (зависит от п.3).
MF>>Что такое меппинг? Не встречал этого понятия в совей практике? Объясните в двух словах не более общий смысл.

AVK>У как все запущено. В РСУБД данные храняться ввиде плоских таблиц, связанных отношениями в иерархическую структуру. Объекты в программе представляют собой структуру сетевую. Преобразование модели данных хранилища в модель данных сервера называется mapping. Судя по твоему выбору тебе нужен OO<->Relational mapping. Создание такого меппинга так чтобы он был не более чем на порядок медленнее обычного обращения на групповых операциях нетривиальная задача в общем то.

Ну не так уж все и запущено Просто не попадались мне в руки книги которые Вы читали и не учился возможно я в нужных институтах, но это не уменьшает моего стремления изучить эту область, и знать!!!
То что придется объекты отражать на плоские таблицы я думал, и даже как то пытался продумать как это сделать. Если укажите книги где можно почитать об этом — то тоже великое Вам спасибо. Особенно об OO<->Relational маппинге

MF>>Бизнес-логике — на сервере приложений (средний уровень), формат хранения??? (непонимаю) если имеется ввиду каким образом будут они подключаться к серверу, то планирую расширяемые модули, плагины (скорее всего ДЛЛ).

AVK>Ага, тут ты похоже даже не думал. Подумай о том что есть технологии динамической компиляции, т.е. приложение можно распространять прямо в исходных текстах, есть xml. Стоит задуматься и о механизме деплоймента. В случае СОМ+ деплоймент превращается в адову работу.

Об адовой работе по деплойменту COM приложений я представление имею, как то пытался это провести на прошлоай работе. Тяжело получалось .

А вот что такое динамическая компиляция и сколько ресурсов нужно будет положить на ее поддержку? представления не имею. Может все таки остановится на DLL (это всетаки мой первый проект, а как написано в книге "Мифический человеко-месяц") первый проект неполучается ниукого, но это не значит что его не нужно делать. Может все таки не насыпать все фишки в одну сборку. Возмжно какая либо поэтапная работа?

AVK>>>6) Схема идентификации и аутентификации
MF>>В этом месте много открытых вопросов. Я их планировал задавать когда приступлю к реализации.

AVK>Низзя. Это очень часто встречающаяся ошибка. Пока ты не продумаешь базовые вопросы нельзя писать ни одной строчки кода, иначе потом придется все переписывать.
Я имелл ввиду что сначала выспрошу у народа, выясню как а потом приступлю к кодированию, но процесс выспрашивания это уже будет фаза "приступлю к реализации". Щас например я еще определяюсь, и нахожусь в том состоянии что ваабще могу все закинуть и продолжать работать на 1С. Но если "приступлю к реализации" назад пути небудет.

MF>> Приблизительно так: данные о пользователях на сервере, у каждого есть права на выполнение операций бизнес-логики а также права на доступ к конкретным объектам бизнес логики и соответсвенно суммирование прав на выполнение операции с правами на доступ к конкретному объекту.

AVK>Как эти права задавать? Где хранить? Как обеспечивать безопасность обмена между сервером и клиентом? Какая политика назначения прав — по уровню, по группе, по индивидуальному пользователю или смешанная. Каким образом организованы объекты доступа — линейно, иерархически, сетевая структура или какая то их смесь?
Как задавать? Будет специальное приложение (чем то похожее на виндовый ЮзерМенеджер)
Где хранить? В базе конечно Если есть более правильный вариант, с удовольствием выслушаю и приму к сведению.
Как обеспечить безопасность? Вот тот я плаваю Жду от Вас многоуважаемая общественность конструктивной помощи. Как можно и как надо
Политика смешанная Группы+Пользователи+Уровень

Что значить линейно, иерархически и все такое (вернее я догадываюсь, и скороее всего будет и то и другое) очень часто будут объекты иерархические но и линейных будет немало. Хотя, если Вы расшифруете что Вы вкладывате в понятие сетевое может будет и сетевое.


AVK>>>7) Схема балансировки
MF>>Не значю что это Надеюсь пока незнаю.

AVK>Схема распределения нагрузки на несколько серверов. Хорошие сервера приложений как правило умеют работать в составе кластера серверов, динамически распределяя между ними нагрузку, а иногда еще и бессбойная (ну или хотя бы со сбоем только у его клиентов) изоляция отказавшего сервера с непрерывностью функционирования кластера в целом.

Нет, в первом моем проекте такого рода, я этим себя загружать не желаю, просто невытяну. Силенок не хватит. Вот когда пооботрусь немного, увижу какой нибудь результат будет видна и схема распределения нагрузки. Так что этот вопрос просто исключаем из рассмотрения (я думаю большого вреда от этого небудет)

MF>>(пока тоже слабо понимаю очем говорят эти три термина) Но думаю у разных объектов будут разные жизненные циклы, как можно говорить об этом заранее?

AVK>Посмотри описание EJB — идея то она везде общая. А планировать жизненные циклы нужно обязательно, это одна из основных характеристик сервера приложений.
Думаю, когда я напишу низкоуровневое ядро я вплотную займусь проектированиме объектов бизнеслогики, вот тогда и буду планировать жизденные циклы объектов.

Учитывая что Вы конкретно описали термины могу теперь точно сказать что большинство объектов будут меня типа Энтити, так как они будут хранится в БД, но будут и такие как стейтлес и стейтфул. Хотя это термины низкого уровня — безотносительно к безнес логике (как я это понимаю) ибо какого типа будет объект можно определить только на этапе проектировани бизнес-логики.

Т.е. сдесь выплывает своеобразное разделение севера среднего уровнян на две категори ядро сервера безотносительно к бизнес-логике и собственно сервер бизнеслогики.


AVK>>>9) Механизм контроля версий.
MF>>Собираюсь просить помощи в этом вопросе у общественности.

AVK>То есть тоже не думал. Плохо.
А какие варианты??? Их не так ужи и много. И кстати я думал Одина из моих мыслей — создавать специальный объект в ядре который будет через специальные интерфейсы определять версию подключаемого компонента и определять возможность его функционирования в контексте процесса сервера. Как это будет работать подробнее — пока не знаю. Но думаю это вполне реально.


AVK>>>10) Алгоритмы кеширования.
MF>>необдумывал

AVK>Без этого производительность твоего сервера будет плачевной. А если еще и OO-Relational меппинг наличествует, то производительность без кеша объектов будет просто никакая.
кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.

AVK>>>11) Конфигурирование.
MF>>Конфигурирование планировалось — параметрическое. т.е. первые версии продукта будут таки сильно стеснены в вопросах конфигурирования. Т.е. под каждую автоматизируемую задачу планировалось написание дополнительных модулей(как для серверов так и для клиентов)

AVK>И тем не менее на дотнете можно реализовать полностью автоматическую систему конфигурирования произвольных модулей. Прообраз такой системы можно поглядеть в янусе ака RSDN@Home.

Обязательно глянем. Но под конфигурированием лично я понимаю — возможность безграмотного в компьютерных понятиях бухгалтера изменить какое либо поведение системы (в переделах допущенных разработчиком). А не возможность крутообученного спеца ковыраясь в ини-файлах или в XML файлах изменить функционал системы в целом. Хотя и это я буду планировать. По возможности так же параметрическим способом Т.е. через какую либо твикующую программу или через диалог "Опции" например
AVK>В джаве на конфигурирование есть стандарт — JMX.

AVK>>>12) Механизмы взаимодействия между клиентом и сервером. В случае .NET это прежде всего Remoting и веб сервисы. Для джавы это RMI.
MF>>Вопрос остается открытым, с моей колоколни — самый главный вопрос- выяснить как передавать наборы записей (например табличную часть накладной) от сервера клиенту???

AVK>Ну я же сказал — ремоутинг или веб-сервисы. Первый много гибче, второй позволит писать клиентов на С++, Дельфи, старом VB, но возможности у него куда как более скудные.
Я не знаю что такое ремотинг или думаю что не знаю (может я о нем знаю совсем по другому названию) если ткнете в статью MSDN где можно о нем почитать. Буду знать лучше. Хотя и вариант вебсервисов скорее всего так же не оставлю без внимания

AVK>Да, совсем забыл — надо еще продумать механизм транзакций, в том числе и распределенных.
Буду стараться укладываться в тарнзакции SQL сервера (это что касается данных). Ну а там где это будет невозможно например транзакция безнес-логики Буду что то выдумывать Кое что чиатл про МТС, не сильно мне нравится егошный подход особенно из-за того что объекты не хранят своих состояний. Хотя даже и незнаю — жду совета от Вас.

MF>>Я надеюсь Вы мне поможете пролить свет на эти вопросы, внести ясность так сказать. Ибо многие из этих вопросов тяжело разрешить самостоятельно в сжатые сроки (ибо как распылены они по литературе достоточно широко)

AVK>В сжатые сроки это сколько конкретно?
Хочется начать уже завтра. Но это к сожалению невозможно . Хочу весь этот мандраж по выяснению возможностей и определению языка реализации уместить в месяца 3-4. Ну а весь проект в 1-2 года.

AVK>>>Для дотнета готового сервера приложений нет, есть возможность интеграции классов .NET в среду СОМ+. То есть тот самый DCOM о котором ты в первом посте поминал.
MF>>Скорее всего буду именно это и использовать. Посему хотелось бы примеров (может банальных, но откражающих суть этого вопроса) Может даже и на MC++

AVK>Смотри в форуме по дотнету. Но там есть подводные камни. Прежде всего очень кривой деплоймент и кое какие неясности с событиями и колбеками.
Я так понимаю что Вы усиленно пытаетесь меня склонить к Джаве Не буду Вас разочаровывать, но пока не попробую на вкус — непойму, я ж все таки хохол А это у нас в крови

Здравствуйте, mvg_first, Вы писали:

MF>Я уже давно прочитал и про COM и про нет. И мало того даже конкретно его применял. И то что поезд Микрософта уже давно мимо него проехал и забыл я тоже понимаю

Так в чём проблемы?

MF>Я так понимаю сидишь ты где нибудь в БАЛЬШУШЕЙ конторе в которой кто-то за тебя очень давно выбрал стратегию работы а тебе только говорят в какую сторону копать,

Не угадал, мне говорят какой нужен функционал, а я уже сам решаю где и куда копать.

MF>и сомневаюсь что ты толком сталкивался с проблемой которую предстоить решить мне.

Если ты внимательно читал мои постинги, где я немножко анализировал свой опыт (пользуясь случаем хочу передать привет ГВ), то ты должен был заметить, что с подобной проблемой я не просто сталкивался, но я её решал и довольно успешно. Эта самодельная комплексная САП, на которой работали (может и сейчас работает) больше десятка больших предприятий, кормила команду разработчиков и меня в том числе более 5 лет. Начинала она делалаться 10 лет назад, но существовала только в DOS версии и, к сожалению, Windows не пережила.

MF>(может я ее некорретно выразил — но она такова, определитmcя с платформой на которой создавать систему автоматизации, при наличии штата программистов в 3-человека, у которых объем знаний — 1С не более. При том что начальство желает занять нишу поставщиков корпоративных АСУ в городе.)

Мда, начальные условия не ахти.

MF>Что мне посоветушеь ответить руководству (котору кстати совершенно пофигу на чем я буду писать — хоть на ассемблере или даже на перфокартах) им важен результат. А я им скажу понимаете тут некий господин IT советует забить на все это потому что мы не потянем и все тут. Потому что мы пытаемся ехать на отсталых технологиях, а если начнем учить мнодные технологии — пройдет время и они поять станут отсталыми. Так что ли?

Разве я тебе советовал забить? Я пытаюсь тебя предостеречь от ошибок, которые ты начинаешь делать ещё не приступив к работе. Хочешь поговорить без понтов и конструктивном ключе? Давай, но только отложи в сторону "я уже решил" и "попрошу мне не указывать". Тогда может что-то и получиться. Я, например, исходя из моего опыта (псхпп ГВ) могу тебе расскать о тех граблять при проектировании и разработки на которые наступал я и моя команда. Кто-то может ещё что-то подскажет, но в таком ключе как ты начал никто тебе помогать не будет.

MF>Или может ты хочешь сказать что изучить JAVU С# и другие языке получиться быстрее чем изучить VC. А единственное тове мнение что я буду сидеь за дебаггером и ловить мемори-лики то что-то мнея берето соменение что Джава такая уж безгрешная.

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

MF>Есть одна поговорка "Шож если они такие умные — то помему они строем не ходят?". Что то я не заметил что бы AXAPTA например была написана на джаве или та же 1С например?

Не переживай, заметишь. Знаешь почему система, которую я делал померла? Потому что затраты на её перевод под Windows были бы не меньше чем вся разработка. Тоже самое касается и 1С. Возможно они хотят всё передалать, но они просто не могут себе это позволить, так как это очень дорого. Другое дело начинать с нуля. К тому же, если тебя действительно интересует распространённость тех или иных технологий, то сходи на любой job сайт и посмотри кто сейчас требуется. Думаю ты будешь сильно удивлён, что Java программистов требуется больше чем C++.

MF>И кстати клиенту у меня есть, и даже не одни. И я точно знаю что 1С — им не нужна

Это хорошо.

MF>А если ты на чужбине то пожалйста не путай подходы ихние с нашими Они разные и очень на много.

Детский сад, штаны на лямках. Ей богу.

MF>Тот же заказчик например. Пришел ко мне и говорит мне нужна система. А я начитавшись разумных книшежек (О RUP и схожих с ними процессах) думаю, спросить у него чего нибудь или сразу сказать — будет сделано. Но по лицу видно что он нифига не знает как должна функционировать система. У нас до сих пор заказчики заказывает системы из престихных соображений а не для улучшения учета или еще чего то там

Говори им что хочешь, это твоё дело. Если ты хочешь здесь обсудить детали разработки АСУ предприяти, то это и надо делать. Если ты хочешь знать что нужно для того чтобы писать трёхзвенку на VC++, то тебе уже сказали: COM, ATL, ADO, MFC. Вперёд, только потом не говори, что тебя не предупреждали.

Здравствуйте, mvg_first, Вы писали:


MF>Книжку эту я купить не могу. Говорят ее выпускать перестали, а в электронном виде нету (на русском)

Где-то нашел на англ. Где -- уже не помню, но могу своей поделиться .
Читается довольно легко. Авторы стараются избегать высокохудожественных оборотов.
Сухое лаконичное техническое описание. То, что доктор прописал!