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

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

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

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

Давай Мыло в профиле

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

А>все же советую дождаться 8-ки (пара месяцев осталась). прикидочно — по мощности (пограммной платформы) сродни платформам типа Scala, Axapta. по цене не знаю. думаю, что проблем с нелицензионкой + документацией в РФ не будет

Слушай, Аноним, а ты Сереге Кравченко передать привет можешь?

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

DMV>VC действительно создан (в первую очередь) для достаточно низкоуровневого программирования. Но не для описания бизнес-логики!
DMV>Посмотри на любую финхоз систему — ядро (конструктор, среда, у кого как) написано с использованием низкоуровненых средств (и то не всегда). А вся бизнес-логика — на каком-то высокоуровневом языке. Непонятно, кстати, всеобщее желание непременно создать свой язык, но это тема для отдельного разговора (вроде уже где-то здесь обсуждалось).

По разному бывает, кстати. У меня бизнес-логика (маршрутизации почтовых отправлений) написана на плюсах. Но у меня требования по времени выполнения на миллисекунды и сумасшедшие потоки вызовов...

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

MF>Спасибо за разъяснение. Но если Вы будете так добры что сможете указать мне литературу желательно в электронном виде, как это приложение сделать Я с удовольствием возьмусь изучать джаву и закину все остальные потуги. А надо мне для этого всего ничего, какой нибудь пошаговый туториал, в котором расписано создание серверной и клиентской части.

Ну я же не зря тебе конкретные сервера приводил. В резине есть тьюториалы прямо в документации. К ориону тьюториал скачивается отдельно. Резиновская дока выложена и в веб. Вот оглавление тьюториалов к примеру:

Tutorial

Introduction to Resin Enterprise
Guided tutorial trail
Field persistence: A CMP bean representing a single database table.
Transactions: Using transactions to protect bean updates.
Find methods and EJB-QL: Finding a course
Creating entries: Adding and removing courses
Container relations: Students in a house
ejbSelect methods: All boys in a house
Catalog of Relations: Common relation types

Устроит?


MF>Но пощупать не знаю как. Один из указанных Вами примеров я скачал, и даже распаковал А что делать дальше как запустить пощупать — незнаю. И где брать джаву к сожалению тоже

Ну там же все просто. Вот тебе пошаговая инструкция
1) Идешь на java.sun.com и скачиваешь J2SE SDK, J2SE SDK Documentation и J2EE. На данный момент последняя версия 1.4
2) Устанавливаешь все это хозяйство
3) Идешь на www.caucho.com и скачиваешь Resin-EE.
4) Распаковываешь архив. В каталоге bin запускаешь httpd.exe. По умолчанию оно слушает порт 8080. Если что то на этом порту весит то убей или поправь файл конфигурации. Первый раз оно будет запускаться довольно долго, так как распаковывает и компилирует все примеры. Дождись появления надписи listening port 8080 on * или что то вроде этого.
5) набираешь в IE http://127.0.0.1:8080 и через некоторое время ты должен увидеть документацию к резину.
6) Находишь секцию Tutorial и следуешь документации.

MF>Ну не так уж все и запущено Просто не попадались мне в руки книги которые Вы читали и не учился возможно я в нужных институтах,

Ты наверное будешь удивлен но последние лет 5 по программированию я прочитал очень мало книг. Конкретно по Java только Брюса Эккеля и то не всю. В институте слово Java не произнес никто Читайте онлайн-документацию, она рулез, поскольку от разработчика и максимально актуальна. Ну и опыт конечно.

MF>но это не уменьшает моего стремления изучить эту область, и знать!!!

Это главное.

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

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

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

В дотнете или джаве деплоймент в хорошо спроектированных приложениях обычно заключается в копировании файла(лов) в определенный каталог. Понимаешь почему СОМ+ не идеальный выбор?

MF>А вот что такое динамическая компиляция

А это правишь исходник — и у тебя сервер, отследив изменение файла, перекомпилирует класс. Резин умудряется даже рекомпильнуть единственный класс, не перезапуская приложение и получается это у него неплохо. Орион тоже рекомпилирует на ходу, но обычно это приводит к Invalid type casting В дотнете схема загрузки-выгрузки классов менее гибкая, так что такое повторить вряд ли удасться. Но с рестартом приложения выйдет вполне неплохо. И ASP.NET тому пример.

MF>и сколько ресурсов нужно будет положить на ее поддержку?

Ты знаешь, как не странно довольно немного. За полдня реально написать прообраз такого менеджера.

MF> Может все таки остановится на DLL

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

MF>Возмжно какая либо поэтапная работа?

Возможна конечно. Но архитектура изначально должна быть заточена под подобные расширения. Ну или отрабатывай концепции отдельно на учебных проектах.

MF>Как задавать? Будет специальное приложение (чем то похожее на виндовый ЮзерМенеджер)

Да я не про приложение. Каким образом это будет привязываться к самим объектам?

MF>Где хранить? В базе конечно Если есть более правильный вариант, с удовольствием выслушаю и приму к сведению.

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

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

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

MF>Нет, в первом моем проекте такого рода, я этим себя загружать не желаю, просто невытяну. Силенок не хватит.

Значит масштабируемость решения будет крайне низкой. х86 архитектура не позволит за разумные деньги сильно превысить возможности серверов в районе 4-5 килобаксов стоимость. Дальнейшее удорожание как правило не привносит адекватного прироста производительности.

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

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

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

Что ты подразумеваешь под понятием низкоуровнего ядра? Какие сервисы ты к нему относишь?

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

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

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

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

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

А механизм наложения версий? А возможность использования CVS или SourceSafe?

MF>кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.
Неа, я речь веду прежде всего о кешах и пулах объектов. И прежде всего entity-объектов. На этом можно очень здорово выиграть в плане производительности. По результатам работы одного реального сервера могу тебе сказать что при грамотном кешировании 80-90% запросов при текущей работе (за исключением построения отчетов) попадают в память без обращения к БД. Причем в памяти висят именно те объекты которые реально используются. Кешированием выборок ты такого не добьешься, эффективность кеша на этом уровне будет заметно ниже.

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

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

Я пока не говорю совсем о внешнем интерфейсе конфигурирования. Речь о параметрах для писателя сервисов к серверу и собственно приложений для него. Автоматическая система конфигурирования сводиться к тому что ты просто говоришь что вот в этом свойстве хранится некий произвольный класс, хранящий твою конфигурацию. Все остальное берет на себя специальный сервис.

MF>Я не знаю что такое ремотинг или думаю что не знаю (может я о нем знаю совсем по другому названию) если ткнете в статью MSDN где можно о нем почитать.

Здесь есть на эту тему моя статья.

MF>Хотя и вариант вебсервисов скорее всего так же не оставлю без внимания

Как вариант — гибкий вариант архитектуры с набором коннекторов для разных методов доступа.

MF>Буду стараться укладываться в тарнзакции SQL сервера (это что касается данных).

Не выйдет. mssql это транзакциолнный ресурс. Сервер же у тебя и транзактный ресурс, да еще и инициатор транзакций. Надо что то придумывать. К примеру перед выполнением защищенного транзакцией куска сериализовать состояние всех вовлеченных объектов и при откате его десериализовать. В общем здесь надо думать.

MF>Кое что чиатл про МТС, не сильно мне нравится егошный подход особенно из-за того что объекты не хранят своих состояний.

DTC? Ну это уже ближе к распределенным транзакциям.

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

Ни в коем случае. Скорее к дотнету

MF>Не буду Вас разочаровывать, но пока не попробую на вкус — непойму, я ж все таки хохол А это у нас в крови

Это куда лучше чем "я буду делать так и даже не отговаривайте".

Как, я тебя еще не испугал

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

W>Сухое лаконичное техническое описание. То, что доктор прописал!

В русском переводе довольно тяжелое описание. Как горькое лекарство — противно, но полезно Но это скорее перевод.

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

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

AVK>

AVK>Tutorial

AVK>Introduction to Resin Enterprise
AVK>Guided tutorial trail
AVK>Field persistence: A CMP bean representing a single database table.
AVK>Transactions: Using transactions to protect bean updates.
AVK>Find methods and EJB-QL: Finding a course
AVK>Creating entries: Adding and removing courses
AVK>Container relations: Students in a house
AVK>ejbSelect methods: All boys in a house
AVK>Catalog of Relations: Common relation types

AVK>Устроит?
Незнаю попробую тогда скажу


AVK>Ну там же все просто. Вот тебе пошаговая инструкция
AVK>1) Идешь на java.sun.com и скачиваешь J2SE SDK, J2SE SDK Documentation и J2EE. На данный момент последняя версия 1.4
AVK>2) Устанавливаешь все это хозяйство
AVK>3) Идешь на www.caucho.com и скачиваешь Resin-EE.
AVK>4) Распаковываешь архив. В каталоге bin запускаешь httpd.exe. По умолчанию оно слушает порт 8080. Если что то на этом порту весит то убей или поправь файл конфигурации. Первый раз оно будет запускаться довольно долго, так как распаковывает и компилирует все примеры. Дождись появления надписи listening port 8080 on * или что то вроде этого.
AVK>5) набираешь в IE http://127.0.0.1:8080 и через некоторое время ты должен увидеть документацию к резину.
AVK>6) Находишь секцию Tutorial и следуешь документации.
Вот такая пошаговая — точно устроит


MF>>Ну не так уж все и запущено Просто не попадались мне в руки книги которые Вы читали и не учился возможно я в нужных институтах,

AVK>Ты наверное будешь удивлен но последние лет 5 по программированию я прочитал очень мало книг. Конкретно по Java только Брюса Эккеля и то не всю. В институте слово Java не произнес никто Читайте онлайн-документацию, она рулез, поскольку от разработчика и максимально актуальна. Ну и опыт конечно.

Чтож буду надеятся что и мне удасться так изучить материал Вроде тоже не меньше 5 лет программированием занимаюсь. И угораздило меня встрять в эту 1С. Попортила мне все

MF>>Как задавать? Будет специальное приложение (чем то похожее на виндовый ЮзерМенеджер)

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

MF>>Где хранить? В базе конечно Если есть более правильный вариант, с удовольствием выслушаю и приму к сведению.

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

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

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

В голове пока это не помещается никак Вот если увижу реальную необходимость — такого графа. Буду думать а пока не представляю себе реального выражения такого подхода.

MF>>Нет, в первом моем проекте такого рода, я этим себя загружать не желаю, просто невытяну. Силенок не хватит.

AVK>Значит масштабируемость решения будет крайне низкой. х86 архитектура не позволит за разумные деньги сильно превысить возможности серверов в районе 4-5 килобаксов стоимость. Дальнейшее удорожание как правило не привносит адекватного прироста производительности.
В последствии будем думать как это работает Скорее всего разные компоненты сервера будут работать на разных физических серверах. И если буду использовать COM — то это несложно Хотя чуствую подводных комней в таком подходе больше чем достаточно.

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

AVK>Что ты подразумеваешь под понятием низкоуровнего ядра? Какие сервисы ты к нему относишь?
Обеспечение безопасности, обработка объектов, механизмы передачи наборов данных. Регистрация объектов, описание объектов. Вообщем работа с метаданными. Неболее.

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

AVK>А механизм наложения версий? А возможность использования CVS или SourceSafe?
Пока меня это только пугает — такие вещи нужно изучать с уже знающим человеком под рукой — иначе смерть

MF>>кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.
AVK>Неа, я речь веду прежде всего о кешах и пулах объектов. И прежде всего entity-объектов. На этом можно очень здорово выиграть в плане производительности. По результатам работы одного реального сервера могу тебе сказать что при грамотном кешировании 80-90% запросов при текущей работе (за исключением построения отчетов) попадают в память без обращения к БД. Причем в памяти висят именно те объекты которые реально используются. Кешированием выборок ты такого не добьешься, эффективность кеша на этом уровне будет заметно ниже.
Т.е. должен быть какой то сервис определяющий выгружать объект из памяти или нет? На основании законов конкретной бизнес задачи? Ну думаю это тоже несложно сделать.

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

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

AVK>Я пока не говорю совсем о внешнем интерфейсе конфигурирования. Речь о параметрах для писателя сервисов к серверу и собственно приложений для него. Автоматическая система конфигурирования сводиться к тому что ты просто говоришь что вот в этом свойстве хранится некий произвольный класс, хранящий твою конфигурацию. Все остальное берет на себя специальный сервис.
Ну это похоже на зачатки искуственного интеллекта. Как должен сервис обучаться??? Если я позже создаю модуль о котором сервис и понятия не имел, и меняю принципы конфигурирования??? Что должен делать сервис даже если я ему дам на вход какйнибудь файл?

MF>>Я не знаю что такое ремотинг или думаю что не знаю (может я о нем знаю совсем по другому названию) если ткнете в статью MSDN где можно о нем почитать.

AVK>Здесь есть на эту тему моя статья.
Вот бы ссылку


MF>>Хотя и вариант вебсервисов скорее всего так же не оставлю без внимания

AVK>Как вариант — гибкий вариант архитектуры с набором коннекторов для разных методов доступа.

MF>>Буду стараться укладываться в тарнзакции SQL сервера (это что касается данных).

AVK>Не выйдет. mssql это транзакциолнный ресурс. Сервер же у тебя и транзактный ресурс, да еще и инициатор транзакций. Надо что то придумывать. К примеру перед выполнением защищенного транзакцией куска сериализовать состояние всех вовлеченных объектов и при откате его десериализовать. В общем здесь надо думать.
Будем думать

AVK>Это куда лучше чем "я буду делать так и даже не отговаривайте".

AVK>Как, я тебя еще не испугал
Испугал??? Чем?

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

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

AVK>

AVK>Tutorial

AVK>Introduction to Resin Enterprise
AVK>Guided tutorial trail
AVK>Field persistence: A CMP bean representing a single database table.
AVK>Transactions: Using transactions to protect bean updates.
AVK>Find methods and EJB-QL: Finding a course
AVK>Creating entries: Adding and removing courses
AVK>Container relations: Students in a house
AVK>ejbSelect methods: All boys in a house
AVK>Catalog of Relations: Common relation types

AVK>Устроит?
Незнаю попробую тогда скажу


AVK>Ну там же все просто. Вот тебе пошаговая инструкция
AVK>1) Идешь на java.sun.com и скачиваешь J2SE SDK, J2SE SDK Documentation и J2EE. На данный момент последняя версия 1.4
AVK>2) Устанавливаешь все это хозяйство
AVK>3) Идешь на www.caucho.com и скачиваешь Resin-EE.
AVK>4) Распаковываешь архив. В каталоге bin запускаешь httpd.exe. По умолчанию оно слушает порт 8080. Если что то на этом порту весит то убей или поправь файл конфигурации. Первый раз оно будет запускаться довольно долго, так как распаковывает и компилирует все примеры. Дождись появления надписи listening port 8080 on * или что то вроде этого.
AVK>5) набираешь в IE http://127.0.0.1:8080 и через некоторое время ты должен увидеть документацию к резину.
AVK>6) Находишь секцию Tutorial и следуешь документации.
Вот такая пошаговая — точно устроит


MF>>Ну не так уж все и запущено Просто не попадались мне в руки книги которые Вы читали и не учился возможно я в нужных институтах,

AVK>Ты наверное будешь удивлен но последние лет 5 по программированию я прочитал очень мало книг. Конкретно по Java только Брюса Эккеля и то не всю. В институте слово Java не произнес никто Читайте онлайн-документацию, она рулез, поскольку от разработчика и максимально актуальна. Ну и опыт конечно.

Чтож буду надеятся что и мне удасться так изучить материал Вроде тоже не меньше 5 лет программированием занимаюсь. И угораздило меня встрять в эту 1С. Попортила мне все

MF>>Как задавать? Будет специальное приложение (чем то похожее на виндовый ЮзерМенеджер)

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

MF>>Где хранить? В базе конечно Если есть более правильный вариант, с удовольствием выслушаю и приму к сведению.

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

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

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

В голове пока это не помещается никак Вот если увижу реальную необходимость — такого графа. Буду думать а пока не представляю себе реального выражения такого подхода.

MF>>Нет, в первом моем проекте такого рода, я этим себя загружать не желаю, просто невытяну. Силенок не хватит.

AVK>Значит масштабируемость решения будет крайне низкой. х86 архитектура не позволит за разумные деньги сильно превысить возможности серверов в районе 4-5 килобаксов стоимость. Дальнейшее удорожание как правило не привносит адекватного прироста производительности.
В последствии будем думать как это работает Скорее всего разные компоненты сервера будут работать на разных физических серверах. И если буду использовать COM — то это несложно Хотя чуствую подводных комней в таком подходе больше чем достаточно.

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

AVK>Что ты подразумеваешь под понятием низкоуровнего ядра? Какие сервисы ты к нему относишь?
Обеспечение безопасности, обработка объектов, механизмы передачи наборов данных. Регистрация объектов, описание объектов. Вообщем работа с метаданными. Неболее.

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

AVK>А механизм наложения версий? А возможность использования CVS или SourceSafe?
Пока меня это только пугает — такие вещи нужно изучать с уже знающим человеком под рукой — иначе смерть

MF>>кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.
AVK>Неа, я речь веду прежде всего о кешах и пулах объектов. И прежде всего entity-объектов. На этом можно очень здорово выиграть в плане производительности. По результатам работы одного реального сервера могу тебе сказать что при грамотном кешировании 80-90% запросов при текущей работе (за исключением построения отчетов) попадают в память без обращения к БД. Причем в памяти висят именно те объекты которые реально используются. Кешированием выборок ты такого не добьешься, эффективность кеша на этом уровне будет заметно ниже.
Т.е. должен быть какой то сервис определяющий выгружать объект из памяти или нет? На основании законов конкретной бизнес задачи? Ну думаю это тоже несложно сделать.

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

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

AVK>Я пока не говорю совсем о внешнем интерфейсе конфигурирования. Речь о параметрах для писателя сервисов к серверу и собственно приложений для него. Автоматическая система конфигурирования сводиться к тому что ты просто говоришь что вот в этом свойстве хранится некий произвольный класс, хранящий твою конфигурацию. Все остальное берет на себя специальный сервис.
Ну это похоже на зачатки искуственного интеллекта. Как должен сервис обучаться??? Если я позже создаю модуль о котором сервис и понятия не имел, и меняю принципы конфигурирования??? Что должен делать сервис даже если я ему дам на вход какйнибудь файл?

MF>>Я не знаю что такое ремотинг или думаю что не знаю (может я о нем знаю совсем по другому названию) если ткнете в статью MSDN где можно о нем почитать.

AVK>Здесь есть на эту тему моя статья.
Вот бы ссылку


MF>>Хотя и вариант вебсервисов скорее всего так же не оставлю без внимания

AVK>Как вариант — гибкий вариант архитектуры с набором коннекторов для разных методов доступа.

MF>>Буду стараться укладываться в тарнзакции SQL сервера (это что касается данных).

AVK>Не выйдет. mssql это транзакциолнный ресурс. Сервер же у тебя и транзактный ресурс, да еще и инициатор транзакций. Надо что то придумывать. К примеру перед выполнением защищенного транзакцией куска сериализовать состояние всех вовлеченных объектов и при откате его десериализовать. В общем здесь надо думать.
Будем думать

AVK>Это куда лучше чем "я буду делать так и даже не отговаривайте".

AVK>Как, я тебя еще не испугал
Испугал??? Чем?

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

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

Может оказаться, что и свой собственный придётся делать. Здесь нужно будет определиться — будет клиент обращаться к конкретным методам прикладных объектов (т.е. — будет он так или иначе, но зависимым от приложения) или будет взаимодействовать с сервером по какому-то своему протоколу, независимому от прикладной конфигурации. Второй вариант привлекательнее, но и сложнее.

AVK>>Судя по твоему выбору тебе нужен OO<->Relational mapping. Создание такого меппинга так чтобы он был не более чем на порядок медленнее обычного обращения на групповых операциях нетривиальная задача в общем то.

MF>Просто не попадались мне в руки книги которые Вы читали и не учился возможно я в нужных институтах, но это не уменьшает моего стремления изучить эту область, и знать!!!

В институтах этому, по-моему, ещё не учат. Ну, во всяком случае — непосредственно.

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

Посмотри для начала на RSDN в разделе Ресурсы/Ссылки/Object-Oriented. Я уже упоминал его в первом ответе.

Мэппинг — достаточно сложная проблема и одна из основных. Тут беда в том, что в открытой сети можно откопать в основном материалы на тему статического отображения (класс — определённая структура таблиц) и полуавтоматической реализации CRUD (т.е. — набора операций Create/Retrive/Update/Delete), а это только базовые вещи на самом деле. (Остальное приватом, если интересно )

Я бы вообще выделил четыре технологических "краеугольных камня" (пусть коллеги меня поправят) :

— Модель бизнес-объекта и его жизненного цикла;
— Security;
— Объектно-реляционное отображение;
— Контроль версий.

MF> это всетаки мой первый проект [...] Возмжно какая либо поэтапная работа?

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

А с поэтапностью легче определяться, когда более или менее ясно прописал всё (или почти всё) на бумаге. Кстати, да — схему (в смысле — алгоритмы для людей и компьютера) деплоймента нужно продумывать тоже сразу.

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

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

MF>Политика смешанная Группы+Пользователи+Уровень

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

Проблема в том, какова детализация объектов доступа. Т.е. — собираешься ли ты управлять доступом к полям и методам конкретного экземпляра или ограничишься классами? Или примешь промежуточный вариант — ограничение доступа на поля/методы класса? Можно по-любому. Разница — в сложности реализации и возможных дальнейших ограничениях.

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

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

MF>[Распределение нагрузки] Так что этот вопрос просто исключаем из рассмотрения (я думаю большого вреда от этого небудет)

По возможности, его надо проработать хотя бы в общих чертах — как переносятся соединения с пользователем, как передаются сотояния объектов между серверами кластера, как выполняется синхронизация кэша, как управлять блокировками. Кстати, распределения нагрузки ты не увидишь (сможешь только предполагать что-то), пока не попытаешься её реально распределить по нескольким физическим серверам.

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

НИ В КОЕМ СЛУЧАЕ ТАК НЕ ДЕЛАЙ! Модель жизненного цикла объекта разрабатывается изначально — это почти что альфа и омега! То есть, сначала ты должен определить возможные виды жизненных циклов объектов (аналогично, скажем, STATEFUL и STATELESS), потом — реализовать необходимую их поддержку в ядре, а только потом, исходя из их возможных комбинаций — проектировать реализацию бизнес-логики. Только не наоборот.

Под моделью ЖЦ я понимаю здесь summary ответов на примерно следующие вопросы:

— Что представляет из себя бизнес-объект? Каковы вариации типов бизнес-объектов?
— Возможно ли их совмещение через наследование, агрегацию? Если да, то как?
— Чем и при каких условиях создаются объекты в памяти? Как отслеживаются?
— Чем и когда они удаляются из памяти? Из базы данных?
— Что происходит с объектами при транзакциях?

Кстати, в литературе ты встретишь разные термины для обозначения одних и тех же вещей. Например, stateless подобен transitive в терминологии Шлеера, а stateful — persistable (аналогично).

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

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

Не совсем так: сервер бизнес-логики, это скорее совокупность ядра и объектов бизнес-логики. Впрочем, это уже терминологическая игра.

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

В принципе — правильно (Смотри, сам ты думаешь, похоже, в основном — правильно, продолжай в том же духе! ), только пока что не полно.

Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).

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

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

Кстати, ты прав тоже — это действительно использование памяти. Вопрос в организации этой памяти и взаимодействиях с окружающим контекстом. Чаще всего для этого пользуются пулом (набором) ранее созданных объектов и здесь сразу появляется проблема в поддержке соответствия "кэш==БД", особенно при групповых операциях обновления.

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

Тут скорее наоборот — нужно уложить транзакции SQL-сервера в твою модель транзакций, которая должна быть объектной. Кстати, модель транзакций тесно связана с моделью жизненного цикла объекта.

Если немного обобщить, то относись к SQL-серверу (любому), как не более чем к средству хранения данных. Сразу снимется часть проблем с поиском оптимального решения с точки зрения MS-SQL и твоего ядра. Кстати, в перспективе, сможешь использовать и MTS.

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

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

Ну, по части 1-2 лет... всё-таки 1 или 2 года? И ещё — 1-2 года на что? На псевдоуниверсальную АСУ? Это не меньше двух лет (учти, тебе ещё аналитиков набирать и прикладников обучать). На ядро? Год в твоём случае — впритык (с отладкой и минимальными рабочими приложениями). По моему опыту (псхпп IT), если через год у тебя вообще ничего не будет работать — пиши пропало. Тебе просто не поверят и другого года просто не дадут.

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

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

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

ГВ>Может оказаться, что и свой собственный придётся делать. Здесь нужно будет определиться — будет клиент обращаться к конкретным методам прикладных объектов (т.е. — будет он так или иначе, но зависимым от приложения) или будет взаимодействовать с сервером по какому-то своему протоколу, независимому от прикладной конфигурации. Второй вариант привлекательнее, но и сложнее.
А бывают не свои собственные???? Я чето не понимаю? Хотя да Бывают — IE — это не мой собственный, согласен Но! Это он будет последний для кого я буду писать ) Так вот мне кажется — хотя и ошибаюсь


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

ГВ>Посмотри для начала на RSDN в разделе Ресурсы/Ссылки/Object-Oriented. Я уже упоминал его в первом ответе.
Глянул — но там все на агнлицком как минимум. Так что буду усердно разбиратся когда дойду до этого в своих конструкторских мучениях.

ГВ>Мэппинг — достаточно сложная проблема и одна из основных. Тут беда в том, что в открытой сети можно откопать в основном материалы на тему статического отображения (класс — определённая структура таблиц) и полуавтоматической реализации CRUD (т.е. — набора операций Create/Retrive/Update/Delete), а это только базовые вещи на самом деле. (Остальное приватом, если интересно )

Конечно интересно. Просто, у меня такая масса вопросов, что проще наверно звонить, чем писать У меня уже пальцы отваливаюстя. Это притом что у меня клава эргономичная, да и печатаю вроде десятью пальцами

ГВ>Я бы вообще выделил четыре технологических "краеугольных камня" (пусть коллеги меня поправят) :

ГВ>- Модель бизнес-объекта и его жизненного цикла;
ГВ>- Security;
ГВ>- Объектно-реляционное отображение;
ГВ>- Контроль версий.

MF>> это всетаки мой первый проект [...] Возмжно какая либо поэтапная работа?
ГВ>Тяжеловатый он для первого проекта, тут я с остальными участниками соглашусь.
Все что легче этого я уже съел и осознал, проблем быть недолжно, а если и будут, то оно все равно включено в текущий проект.

ГВ>А с поэтапностью легче определяться, когда более или менее ясно прописал всё (или почти всё) на бумаге. Кстати, да — схему (в смысле — алгоритмы для людей и компьютера) деплоймента нужно продумывать тоже сразу.
Ага, я для этого дела даже книжку купил Крейга Лармана. UML и шаблоны проектирования. Но как то невлезает она в мою хохляцкую голову без практики, а практикой заняться не могу, нет учителя которому можно дать на проверку задание

MF>>Политика смешанная Группы+Пользователи+Уровень

ГВ>Ну вот, на самом главном ты плаваешь. Какой рисовалкой пользоваться — отдельным приложением, или, скажем, модулем, написанным как часть твоей системы — это уже второстепенно, хотя и не скажу, что "неважно".

ГВ>Проблема в том, какова детализация объектов доступа. Т.е. — собираешься ли ты управлять доступом к полям и методам конкретного экземпляра или ограничишься классами? Или примешь промежуточный вариант — ограничение доступа на поля/методы класса? Можно по-любому. Разница — в сложности реализации и возможных дальнейших ограничениях.
Если честно, то хочу завязаться с SECURITY по самые помидоры, но переживаю как бы не загубило оно мне проект, по скоростным показателям. А какой компромис выбрать -незнаю, ибо не знаю механизмов реализации различных спобов обсуждавшихся ранее. Одно точно, не хочу делать это средствами SQL вернее полностью (частично все таки придется)

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

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

MF>>[Распределение нагрузки] Так что этот вопрос просто исключаем из рассмотрения (я думаю большого вреда от этого небудет)

ГВ>По возможности, его надо проработать хотя бы в общих чертах — как переносятся соединения с пользователем, как передаются сотояния объектов между серверами кластера, как выполняется синхронизация кэша, как управлять блокировками. Кстати, распределения нагрузки ты не увидишь (сможешь только предполагать что-то), пока не попытаешься её реально распределить по нескольким физическим серверам.
Вот именно, но после того как Вы сказали о некоторых деталях этого распределения — то можно уже и задуматься.

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

ГВ>НИ В КОЕМ СЛУЧАЕ ТАК НЕ ДЕЛАЙ! Модель жизненного цикла объекта разрабатывается изначально — это почти что альфа и омега! То есть, сначала ты должен определить возможные виды жизненных циклов объектов (аналогично, скажем, STATEFUL и STATELESS), потом — реализовать необходимую их поддержку в ядре, а только потом, исходя из их возможных комбинаций — проектировать реализацию бизнес-логики. Только не наоборот.
Да??? А как я буду определять модель жизненного цикла объекта "шестеренка" если на первом этапе я не собираюсь приступать к реализации бизнес логики, а хочу все силы кинуть на формирование ядра???

ГВ>Под моделью ЖЦ я понимаю здесь summary ответов на примерно следующие вопросы:

ГВ>- Что представляет из себя бизнес-объект? Каковы вариации типов бизнес-объектов?
Очень абстрактный вопрос — очень тяжелоно на него ответить, очитвая что бизнес объектов на предприятии среднего уровня около 1000 и более Если хорошо поискать конечно.
ГВ>- Возможно ли их совмещение через наследование, агрегацию? Если да, то как?
Думаю возможно, один из аргументов по которым хочу писать свою систему — это возможность управления наследованием и агрегацией (я лично очень сомневаюсь что в 8 такая фича будет)
ГВ>- Чем и при каких условиях создаются объекты в памяти? Как отслеживаются?
Вот этот вопрос я обдумывал, для каждой категории бизнесобъектов будет своеобразный "менеджер" который будет заниматся их созданием уничтожением, и наверное и маппингом, и даже кешированием.
ГВ>- Чем и когда они удаляются из памяти? Из базы данных?
ГВ>- Что происходит с объектами при транзакциях?
Скорее всего как уже предлагалось ранее будет какая нибудь сериализация при транзакциях с контролем safepoint-ов.

ГВ>Кстати, в литературе ты встретишь разные термины для обозначения одних и тех же вещей. Например, stateless подобен transitive в терминологии Шлеера, а stateful — persistable (аналогично).

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

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

ГВ>Не совсем так: сервер бизнес-логики, это скорее совокупность ядра и объектов бизнес-логики. Впрочем, это уже терминологическая игра.
Согласен.

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

ГВ>В принципе — правильно (Смотри, сам ты думаешь, похоже, в основном — правильно, продолжай в том же духе! ), только пока что не полно.

ГВ>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).
Да я уже думал что будет два типа объектов поддерживающих хотсвап и неподдерживающих. Т.е. если объект поддерживает хотсвап то сервис обновелния загружает его в систему сразу после прекращения использования всех его экзепляров. Если не поддерживает, производится перезагрузка сервера, холодный старт, пересборка или еще чего либо там.

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

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

ГВ>Кстати, ты прав тоже — это действительно использование памяти. Вопрос в организации этой памяти и взаимодействиях с окружающим контекстом. Чаще всего для этого пользуются пулом (набором) ранее созданных объектов и здесь сразу появляется проблема в поддержке соответствия "кэш==БД", особенно при групповых операциях обновления.

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

ГВ>Тут скорее наоборот — нужно уложить транзакции SQL-сервера в твою модель транзакций, которая должна быть объектной. Кстати, модель транзакций тесно связана с моделью жизненного цикла объекта.

ГВ>Если немного обобщить, то относись к SQL-серверу (любому), как не более чем к средству хранения данных. Сразу снимется часть проблем с поиском оптимального решения с точки зрения MS-SQL и твоего ядра. Кстати, в перспективе, сможешь использовать и MTS.

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

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

ГВ>Ну, по части 1-2 лет... всё-таки 1 или 2 года? И ещё — 1-2 года на что? На псевдоуниверсальную АСУ? Это не меньше двух лет (учти, тебе ещё аналитиков набирать и прикладников обучать). На ядро? Год в твоём случае — впритык (с отладкой и минимальными рабочими приложениями). По моему опыту (псхпп IT), если через год у тебя вообще ничего не будет работать — пиши пропало. Тебе просто не поверят и другого года просто не дадут.
Это я понимаю, поэтому и продолжаем писать на 1С, а не "уходим под лед"

Пожалуйста, оставляйте в ответах только необходимую часть исходного сообщения. Не стоит цитировать его целиком.

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

ГВ>Может оказаться, что и свой собственный придётся делать. Здесь нужно будет определиться — будет клиент обращаться к конкретным методам прикладных объектов (т.е. — будет он так или иначе, но зависимым от приложения) или будет взаимодействовать с сервером по какому-то своему протоколу, независимому от прикладной конфигурации. Второй вариант привлекательнее, но и сложнее.

Ещё можно свою операционку написать, тоже будет очень привлекательно

ГВ>Я бы вообще выделил четыре технологических "краеугольных камня" (пусть коллеги меня поправят) :

ГВ>- Модель бизнес-объекта и его жизненного цикла;
ГВ>- Security;
ГВ>- Объектно-реляционное отображение;
ГВ>- Контроль версий.

Я бы ещё добавил мониторинг, статистику и логирование, которые нужно зашивать в сервер изначально. Под хорошей нагрузкой — это единственный способ понять что происходит в системе.

MF>>[Распределение нагрузки] Так что этот вопрос просто исключаем из рассмотрения (я думаю большого вреда от этого небудет)

Кластеры и лоадбалансеры могут применяться не только для распределения нагрузки, но ещё и для повышения надёжности системы. Если отваливается один сервер, то второй продолжает работать. Поэтому отмахиваться от этого не стоит. К тому же (как правильно говорят мои коллеги (псхпп)), построив систему без учёта этих возможносей ты уже не сможешь её переделать малой кровью. Ошибки в проектировании таких вещей являются наиболее дорогостоящими. Дороже могут быть только ошибке в дизайне базы данных.

ГВ>По возможности, его надо проработать хотя бы в общих чертах — как переносятся соединения с пользователем, как передаются сотояния объектов между серверами кластера, как выполняется синхронизация кэша, как управлять блокировками. Кстати, распределения нагрузки ты не увидишь (сможешь только предполагать что-то), пока не попытаешься её реально распределить по нескольким физическим серверам.

На этих задачах можно состариться и так и не увидеть своё детище в производстве. Железный, проверенный способ поддержки распределённой нагрузки — stateless модель для объектов хранимых в базе данных. Stateful только для очень редкоизменяемых объектов.

ГВ>Под моделью ЖЦ я понимаю здесь summary ответов на примерно следующие вопросы:

ГВ>- Что представляет из себя бизнес-объект? Каковы вариации типов бизнес-объектов?
ГВ>- Возможно ли их совмещение через наследование, агрегацию? Если да, то как?
ГВ>- Чем и при каких условиях создаются объекты в памяти? Как отслеживаются?
ГВ>- Чем и когда они удаляются из памяти? Из базы данных?
ГВ>- Что происходит с объектами при транзакциях?

Так же обрати внимание на частоту использования объектов и стоит ли их вообще держать в памяти или кешировать. Может получиться так что твоя память или кеш будет забита объектами, которые долгое время никому не нужны и смысла в применении подобных вещей нет. Так обычно просиходит с большинством рабочих объектов, таких как проводка в бухгалтерии или счёт кастомера. Здесь тебе как раз и поможет статистика и мониторинг, о которых я говорил ранее.

ГВ>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).

stateless, только stateless.

ГВ>Если немного обобщить, то относись к SQL-серверу (любому), как не более чем к средству хранения данных. Сразу снимется часть проблем с поиском оптимального решения с точки зрения MS-SQL и твоего ядра. Кстати, в перспективе, сможешь использовать и MTS.

Мда, советик ещё тот
SQL сервер — сердце системы и к нему нужно относится бережно и трепетно, лелеять и холить. Неоптимальная организация данных или неоптимальные запросы могут просадить всю систему так, что не помогут и десяток апп-серверов. Что можно и нужно сделать — это выделить всю работу с базой в отдельный слой и уже даже на уровне ядра не иметь дела не только с именами таблиц, но даже с именами полей. Только через структуры данных и/или типизированные датасеты. Это мероприятие следует рассматривать как гигиеническое и так к нему и относиться. Ты же в конце концов не спрашиваешь себя зачем ты каждый день чистишь зубы, просто так надо

Ещё немного от себя из своего э... ГВ знает.

1. Разработка должна вестись на реально-предполагаемых объёмах данных, в противном случае поведение системы во время эксплуатации будет непредсказуемым и её ресурс производительности будет быстро исчерпан в совершенно неожиданных местах.

2. Для всех пакетных операций обработки данных бизнес-уровень идёт лесом и они выполняются только сохранёнными процедурами самого SQL сервера. В противном случае — медленная смерть при росте объёма данных. SQL сервер справляется с такими задачами в разы, а иногда и десятки раз быстрее. К тому же их можно повесить на расписание в часы, когда сервер не загружен основными задачами.

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

4. Unit-тестирование.

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

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


IT>Кластеры и лоадбалансеры [......] Дороже могут быть только ошибке в дизайне базы данных.

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

IT>На этих задачах можно состариться и так и не увидеть своё детище в производстве. Железный, проверенный способ поддержки распределённой нагрузки — stateless модель для объектов хранимых в базе данных. Stateful только для очень редкоизменяемых объектов.

СтайтЛесс — это ведь объекты не хранящие своего состояния так? Т.е. те которые загружаются каждый раз из базы если с ним необходиом сделать какое либо действие, и уничтожающиеся после окончания этого действия? Так я понимаю? Т.е. основная нагрузка ложится на канал между АППСеврером и SQL сервером? Если у меня большое количество клиентов будет работать с этими объектами? то как же тогда выполнять кеширование??? И не будет ли узким местом слишком частые запросы к SQL серверу?

ГВ>>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий.[....]
IT>stateless, только stateless.
Ну если так, то да Но нафиг тогда иметь объекты (и средний уровень вообще, несчитаю секюрити канечно ) — если одна из их прелестей (скажем так, та которая мне нравится больше всего) будет отключена (я имею ввиду состояние объекта, и поведение объекта зависящее от его состояния) хотя опять же — могу ведь и ошибаться. Прошу несколько просветить меня в этом вопросе.

ГВ>>Если немного обобщить, то относись к SQL-серверу (любому), как не более чем к средству хранения данных. Сразу снимется часть проблем с поиском оптимального решения с точки зрения MS-SQL и твоего ядра. Кстати, в перспективе, сможешь использовать и MTS.

IT>Мда, советик ещё тот
IT>SQL сервер — сердце системы и к нему нужно относится бережно и трепетно, лелеять и холить. Неоптимальная организация данных или неоптимальные запросы могут просадить всю систему так, что не помогут и десяток апп-серверов. Что можно и нужно сделать — это выделить всю работу с базой в отдельный слой и уже даже на уровне ядра не иметь дела не только с именами таблиц, но даже с именами полей. Только через структуры данных и/или типизированные датасеты. Это мероприятие следует рассматривать как гигиеническое и так к нему и относиться. Ты же в конце концов не спрашиваешь себя зачем ты каждый день чистишь зубы, просто так надо
Поддерживаю, даже когда пишу на 1С трачу не один день на вылизывание SQL запросов (я работаю напрямую, забил болт на запросы 1С )

Со всем остальным согласен, принял к сведению. Буду использовать. Весьма признателен и за следующие советы и подсказки.

Да, чуть незабыл мне тут насоветовали книжечку
"Разработка масштабируемых приложений для Windows." Мастер-класс
Дайте рецензию плиз.
Или посоветуйте аналогичную.

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

MF>СтайтЛесс — это ведь объекты не хранящие своего состояния так? Т.е. те которые загружаются каждый раз из базы если с ним необходиом сделать какое либо действие, и уничтожающиеся после окончания этого действия? Так я понимаю? Т.е. основная нагрузка ложится на канал между АППСеврером и SQL сервером? Если у меня большое количество клиентов будет работать с этими объектами? то как же тогда выполнять кеширование??? И не будет ли узким местом слишком частые запросы к SQL серверу?
Нет, тут дело в восприятии объектов. Stateless объекты лучше воспринимать как глаголы, а не как существительные. Т.е. вместо объекта "рейс", у которого есть множество объектов-мест, у каждого из которых можно изменить признак "зарезервирован", и даже вместо объекта "рейс", у которого есть свойство "количество свободных мест", делается объект "резервирование билета". У него есть метод "поехали" — который и выполняет глагол, и, возможно, набор свойств, которые описывают как выполнять это главное действие. Типа номера рейса, класса салона... Для его работы вообще не надо ничего кэшировать. В случае грамотно спроектированного нижнего уровня выполнение метода "поехали" может свестись к вызову "update reservation set free_seats = free_seats-1 where reservation_id='S73337'", который вообще не требует подъема чего-либо в память, а соответствие количества проданных билетов количеству мест самолета гарантируется check constraint на free_seats>=0.
IT>>stateless, только stateless.

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

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

S>Нет, тут дело в восприятии объектов. Stateless объекты лучше воспринимать как глаголы, а не как существительные. Т.е. вместо объекта "рейс", у которого есть множество объектов-мест, у каждого из которых можно изменить признак "зарезервирован", и даже вместо объекта "рейс", у которого есть свойство "количество свободных мест", делается объект "резервирование билета". У него есть метод "поехали" — который и выполняет глагол, и, возможно, набор свойств, которые описывают как выполнять это главное действие. Типа номера рейса, класса салона... Для его работы вообще не надо ничего кэшировать. В случае грамотно спроектированного нижнего уровня выполнение метода "поехали" может свестись к вызову "update reservation set free_seats = free_seats-1 where reservation_id='S73337'", который вообще не требует подъема чего-либо в память, а соответствие количества проданных билетов количеству мест самолета гарантируется check constraint на free_seats>=0.
Но ведь объекты существительные так же нужны? Или по Вашему мнению от них можно отказаться?
S>

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

S>Нет, тут дело в восприятии объектов. Stateless объекты лучше воспринимать как глаголы, а не как существительные. Т.е. вместо объекта "рейс", у которого есть множество объектов-мест, у каждого из которых можно изменить признак "зарезервирован", и даже вместо объекта "рейс", у которого есть свойство "количество свободных мест", делается объект "резервирование билета". У него есть метод "поехали" — который и выполняет глагол, и, возможно, набор свойств, которые описывают как выполнять это главное действие. Типа номера рейса, класса салона... Для его работы вообще не надо ничего кэшировать. В случае грамотно спроектированного нижнего уровня выполнение метода "поехали" может свестись к вызову "update reservation set free_seats = free_seats-1 where reservation_id='S73337'", который вообще не требует подъема чего-либо в память, а соответствие количества проданных билетов количеству мест самолета гарантируется check constraint на free_seats>=0.

Именно так.

Вообще ООП модель объектов имея неоспоримые преимущества, страдает рядом серьёзных недостатков, которые выливаются в результате в торомоза и большую сложность и запутанность системы, порой совершенно неоправданно. Пример, объект "Гайка номер M56 инвентарный номер Г560032345 из ящичка Я27". Вероятность повторного обращения к такому объекту в течении ближайших суток часто стремится к нулю. Зачем в таком случае тратить ресурсы на хранение этого объектв в памяти.

Модель объектов интенсивно используется в Ява-серверах, но как упоминал AVK, один из наиболее серьёзных недостатков у них — тормознутость. MS пропагандирует больше stateless модель, которая лично мне импонирует больше. Тем не менее кеширование нужно и оно действительно может очень здорово повысить производительность системы. Но подходить к этому нужно аккуратно, т.к. может получиться совершенно обратный результат.

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

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

MF>Но ведь объекты существительные так же нужны? Или по Вашему мнению от них можно отказаться?
По моему мнению — нет Я мечтаю о системе, которая будет работать с entity-объектами без страшных performance penalty.
Но в существующей реальности IT прав. Либо stateful, либо перформанс...

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

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

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

Т.е. это понятие должно быть конфигурируемым??? Разрабочик бизнес компоненты должен будет зарегистрировать все объекты и указать системе какой у них жизненный цикл? Так я понимаю? Или разработчик безнес объекта должен сам реализовывать жизенный цикл его объектов.
Если первый вариант то мне видится только один вариант реализации сервер приложений должен выставлять фасадные заглушки с которыми работает пользователь (бизнес-программист прикладник) а уж вызовы методов этих заглушек интерпретировать в зависимости от зарегестрированного состояния объекта. Толи из кеша подымать, толи из базы стейтлесс объет загрузить выполнить и удалить??? Так? Я понимаю

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

MF>Но ведь объекты существительные так же нужны? Или по Вашему мнению от них можно отказаться?

Эту функциональность можно эмулировать.

Можно поступить следующим образом:

1. При запросе клиентом объект сериализуется и отдаётся ему полностью или частично (в случае сложных объектов). Далее клиент работает с этим объектом независимо и самостоятельно решает как долго ему жить. Т.е. кеширование осуществляет клиент. При этом под клиентом нужно понимать не только клиентскую машину, но и любую часть системы, выступающую в роли потребителя данных.

2. Обычно первый запрос объекта делается по его читабельному номеру (например, номер счёта). После того как объект считан и передан клиенту, клиент использует для обращения ID объекта в базе данных. Если такое обращение (по ID) имеет место быть, то такой объект можно положить и в кеш, т.к. вероятность третьего обращения к данному объекту весьма высока.

А как быть с синхронизацией доступа к кешу и с синхронизацией объекта в кеше и БД?

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

MF>Во!!! А я то думаю что еще впихнуть в сервер Статистику!!! Вот это та еще задача. Спасибо Вам большое много уважаемый IT!!!

Впихивать её не надо. В Windows есть классный механизм каунтеров, а в .NET поддержка этого дела. Разрабатывешь свой набор счётчиков и тебе уже сразу доступен мониторинг в лучшем виде. К тому же, так как это стандартная фича операционки, то вполне возможна обработка данной информации сторонными продуктами.

ЗЫ. Давай на ты, а то я как-то того...

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

Вот это я рекомендую всем Application Architecture for .NET: Designing Applications and Services.

MF>СтайтЛесс — это ведь объекты не хранящие своего состояния так? Т.е. те которые загружаются каждый раз из базы если с ним необходиом сделать какое либо действие, и уничтожающиеся после окончания этого действия? Так я понимаю? Т.е. основная нагрузка ложится на канал между АППСеврером и SQL сервером? Если у меня большое количество клиентов будет работать с этими объектами? то как же тогда выполнять кеширование??? И не будет ли узким местом слишком частые запросы к SQL серверу?

Индивидуальный подход к каждому типу объектов. Например справочник проводок я бы закачивал не раздумывая при старте сервера и больше о нём не думал.

MF>"Разработка масштабируемых приложений для Windows." Мастер-класс
MF>Дайте рецензию плиз.

Не читал