Здравствуйте, Serginio1, Вы писали:
S> Так нормализация в РБД тянет за собой огромный индекс на подчиненные связи, где это как в нормальном программировании решается на двух напрвленными списками. Экономия на вставку и удаление, а так же надежность.
Это заблуждение. Нормализация никакого отношения к индексам не имеет. В реляционной алгебре вообще нет такой сущности, как индекс. А нормализация определяется в терминах РА.
Индексы в реляционных базах введены как раз для ускорения операций. S> Репликация в РБД хорошо вписывается, т.к. связи построены с применением инндексов, а не прямой или коственной (номер записи) ссылки.
Ты, похоже, неправильно понимаешь термин "индекс". Индексы не имеют никакого отношения к репликации. Если ты имеешь в виду то, что записи идентифицируются первичным ключом, т.е. значениями атрибутов, то да — это помогает реплицироваться.
S> Теперь объясню почему мне не нравится SQL. Если посмотреть на затраты разбора инструкций Insert, Update итд при может тратится намного больше времени чем сама вставка. Я сторонник прямого доступа с ранним связыванием, особенно когда база не изменяется и не требуется работа с удаленными БД.
Ну давай посмотрим. Дла сверхкоротких запросов такая ситуация может иметь место, но таких запросов в конечной системе не может быть много. Для оптимизации фазы синтаксического разбора все современные СУБД предоставляют двухстадийный механизм — подготовку стейтмента, и собственно выполнение. Между первой и второй стадиями могут менять параметры, и вторую стадию можно выполнять многократно. Т.е. мы выполнили связывание, получив предкомпилированный запрос, и потом выполняем его миную синтаксический разбор. S> И когда приводят тесты со временем за часы сразу вспоминаю любимые ДВК-2.
Хм. Самый хреновый результат из опубликованных МС в TPC-C составляет около девяти тысяч транзакций в минуту. Сервер — машинка с гигагерцовым PIII. Т.е. послабже нонешнего десктопа. При этом транзакция — это нифига не инкремент каунтера, это ввод заказа на товар, средним размером 10 позиций, в систему, где параллельно выполняются еще всякие запросы. Может, я не так понял, и ты говоришь про XML? S> Но у РБД очень много премуществ прежде всего в простоте использования и конфигурирования БД.
Ну естественно. На самом деле, в большинстве случаев попытка родить что-то свое приведет к тому, что либо пострадает надежность (ACID properties), либо производительность, либо и то и другое. А если вдруг удастся сохранить и то и другое, то внести любое изменение будет стоить просто безумных затрат. S>А раз за этим еще стоят монстры индустрии то конкурирующие подходы не нужны.
Подходы — нужны. Иначе зачем монстрам развивать свои продукты? S>Хотя специализированные БД нужно писать с высокой оптимизацией с применением различных списфиских алгоритмов, где SQL и РБД сильно проигрывают особенно на сильно разветвленных БД и применеием иерархии (свинное ухо).
Согласен. РБД — не панацея. Просто потому, что большинство из них садится в лужу на "простейших" запросах типа select * from plane where (x-x0)*(x-x0)+(y-y0)*(y-y0)<R*R
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>О-о-о, наш человек, наш. Все, сдаю английский и начинаю новую жизнь. Мое мнение
Спасибо, большое.
В списке литературы у вас в основном ACMовские издания. Что это такое знаю — на олимпиаду ездил 2 раза. Сейчас тренирую команду. Известны ли вам какие-либо книги переведенные на русский язык посвященные теоритическим аспектам ООБД?
Про "объектную" обертку над реляционными БД (чисто структурная реализация). Пытался реализовать нечто подобное летом. Пробовал на "обертке" решить задачу выборки фирм с телефонами начинающимися с цифр 35 (фирм 20000, телефонов 200000). Результаты впечатлили: Interbase и Oracle (!) упали (уснули и не проснулись). Аналогичное решение на SQL Servere отработало за 0,5 секунды.
В чем прикол — до сих пор не понял.
Простите что долго не было — Интернет только появился.
Вы писали:
B>На самом деле в реляционных БД больше проблем B>Вот самые существенные на наш взгляд: B>1. "Бессмысленность" данных, хранящихся в БД, т.е. интерпретация "смысла" данных в БД лежит либо непосредственно на пользователе, либо на прикладном алгоритме. B>2. Слабые выразительные возможности. Если в системе невозможно в явном виде отобразить ту или иную информацию, то это приводит либо к потере данной информации, либо к ее искажению, что в свою очередь влечет за собой построение "упрощенной" модели, отображающий не саму задачу, а "взгляд" на решение задачи с позиции текущих требований. B>3. "Жесткость" структур хранения информации...
Абсолютно со всем согласен. Спасибо за аргументы. чем их больше — тем легче мне на душе.
B>Для решения этих (и других проблем) в нашем коллективе разработана База Знаний, с собственным языком описания знаний. Есть реализованные коммерческие проекты. B>Так что эта тема нам очень даже близка B>Если есть вопросы — пишите...
Вопросы есть, конечно.
Какую модель представления данных вы использовали?
Каков характер связки — данные/алгоритмы?
В каких предметных областях использовали?
Удобство разработки?
Производительность?
и т.д. и т.п.
Если можно — краткое описание системы в электронном виде.
Здравствуйте, AndrewVK, Вы писали:
AVK>В этом случае как правило данные храняться ввиде набора правил, состоящих из предиката, описывающего применимость правила и тела. Тело может быть либо написанным на алгоритмическом языке, либо какой то другой структурой, например графом, который может быть представлен тем же XML. В любом случае выбирать правило надо все целиком, а в таких
условиях реляционной структуры, хранящей тело в блобе более чем достаточно.
Все это само собой. Но что в блобе то хранится — XML, например? Если так то структура уже не чисто реляционная.
M>>Проблема вернулась в новом лице после защиты. Новое лицо — документооборот. Хороший документооборот — гибкий документооборот. Формы и состав документов могут меняться во времени и это не должно отражаться на системе в целом. AVK>Как то давно, когда я был совсем молодой, видел я как вели учет наши деды, на бумаге без компьютеров. Так вот — хранили они данные исключительно в реляционном виде .
Хмм... Но 3NF там точно не пахло. Потом, учет — еще не документооборот. Там такие "документики" попадаются, типа "Проиказ такой-то от такого-то числа. Считать в приказе на отчисление номер такойто студентку Алтунину Марию Алтуниной Ринатой". Причем обе студентки существуют.
Формы документов изменяются в последнее время довольно часто. Меняется даже состав некоторых документов — яркий пример ИНН ввели и сказали он нужен там-то и там-то. Еще через год скажут, вот здесь-то он тоже нужен, а здесь нам все равно.
И что — каждый раз проводить "технические" дни — перестраивать схему БД, останавливать работу вуза. Гибкость системы документооборота — это умение перестраиваться на ходу, не останавливаясь, это постоянная "совместимость" со старыми видами документов и в тоже время не зависимость от них.
Чем мне импонируют ООБД — эти задачи решаются в них двумя словами — наследование + полиморфизм.
M>>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. AVK>Сможет, если немного повозится. Другое дело что в терминах ОО мыслить проще.
Модель ООБД (обертку) тоже можно построить на базе реляционной БД (наоборот кстати тоже). Только возиться надо долго.
Здравствуйте, Morgun, Вы писали: M>В списке литературы у вас в основном ACMовские издания. Что это такое знаю — на олимпиаду ездил 2 раза. Сейчас тренирую команду. Известны ли вам какие-либо книги переведенные на русский язык посвященные теоритическим аспектам ООБД?
Увы, лично мне такие книги неизвестны. Более того, мне неизвестны даже англоязычные книги на эту тему. Ну, кроме собсно ODMG. M>Про "объектную" обертку над реляционными БД (чисто структурная реализация). Пытался реализовать нечто подобное летом. Пробовал на "обертке" решить задачу выборки фирм с телефонами начинающимися с цифр 35 (фирм 20000, телефонов 200000). Результаты впечатлили: Interbase и Oracle (!) упали (уснули и не проснулись). Аналогичное решение на SQL Servere отработало за 0,5 секунды. M>В чем прикол — до сих пор не понял.
Скорее всего какой-то стеб с индексами. Если вдруг для этого поля был хеш-индекс, то придется делать scan вместо seek. Хотя даже при table scan несчастные 200 килозаписей не должны смущать приличный сервер.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Так нормализация в РБД тянет за собой огромный индекс на подчиненные связи, где это как в нормальном программировании решается на двух напрвленными списками. Экономия на вставку и удаление, а так же надежность. S>Это заблуждение. Нормализация никакого отношения к индексам не имеет. В реляционной алгебре вообще нет такой сущности, как индекс. А нормализация определяется в терминах РА.
S>Индексы в реляционных базах введены как раз для ускорения операций. S>> Репликация в РБД хорошо вписывается, т.к. связи построены с применением инндексов, а не прямой или коственной (номер записи) ссылки. S>Ты, похоже, неправильно понимаешь термин "индекс". Индексы не имеют никакого отношения к репликации. Если ты имеешь в виду то, что записи идентифицируются первичным ключом, т.е. значениями атрибутов, то да — это помогает реплицироваться.
Я имею ввиду, что связи в РБД построены на первичных ключах (индексах, хэш таблиц) но в основном первичный ключ представляет индекс ( хотя в параддоксе это скорей всего иерархический массив), а не ссылках. Но например на многострочную часть документа обычно применяется составной индекс, а таковых записей за миллионы.
S>> Теперь объясню почему мне не нравится SQL. Если посмотреть на затраты разбора инструкций Insert, Update итд при может тратится намного больше времени чем сама вставка. Я сторонник прямого доступа с ранним связыванием, особенно когда база не изменяется и не требуется работа с удаленными БД. S>Ну давай посмотрим. Дла сверхкоротких запросов такая ситуация может иметь место, но таких запросов в конечной системе не может быть много. Для оптимизации фазы синтаксического разбора все современные СУБД предоставляют двухстадийный механизм — подготовку стейтмента, и собственно выполнение. Между первой и второй стадиями могут менять параметры, и вторую стадию можно выполнять многократно. Т.е. мы выполнили связывание, получив предкомпилированный запрос, и потом выполняем его миную синтаксический разбор.
Согласен. Но параметры все равно разбирать приходится. В итоге приходим в удаленным процедурам аля Net Remoting. И зачем тогда SQL нужен??? В большинстве случаев это уже жестко забитые запросы. Плюс ограничение на длину запроса и из-за этого различные ухищрения .
ООП уже сколько на дворе. А SQL непобедим. Особенно мне нравится смотреть на сложные запросы с огромным количеством подзапросов, джоинов и юнионов + темповых таблиц, или загрузка из текстовых данных и последнее время из XML.
По большому счету я не против РБД иногда без них никак, но против SQL. Хотя раньше был от него в восторге.
S>> И когда приводят тесты со временем за часы сразу вспоминаю любимые ДВК-2. S>Хм. Самый хреновый результат из опубликованных МС в TPC-C составляет около девяти тысяч транзакций в минуту. Сервер — машинка с гигагерцовым PIII. Т.е. послабже нонешнего десктопа. При этом транзакция — это нифига не инкремент каунтера, это ввод заказа на товар, средним размером 10 позиций, в систему, где параллельно выполняются еще всякие запросы. Может, я не так понял, и ты говоришь про XML?
На сайте Cashe. http://www.intersystems.ru/cache/cache_vs_oracle.html
S>> Но у РБД очень много премуществ прежде всего в простоте использования и конфигурирования БД. S>Ну естественно. На самом деле, в большинстве случаев попытка родить что-то свое приведет к тому, что либо пострадает надежность (ACID properties), либо производительность, либо и то и другое. А если вдруг удастся сохранить и то и другое, то внести любое изменение будет стоить просто безумных затрат.
А почему бы не разделить подходы. И не валить все в одну кучу.
S>>А раз за этим еще стоят монстры индустрии то конкурирующие подходы не нужны. S>Подходы — нужны. Иначе зачем монстрам развивать свои продукты?
Может Net сдвинет эту скалу. S>>Хотя специализированные БД нужно писать с высокой оптимизацией с применением различных списфиских алгоритмов, где SQL и РБД сильно проигрывают особенно на сильно разветвленных БД и применеием иерархии (свинное ухо). S>Согласен. РБД — не панацея. Просто потому, что большинство из них садится в лужу на "простейших" запросах типа select * from plane where (x-x0)*(x-x0)+(y-y0)*(y-y0)<R*R
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Увы, лично мне такие книги неизвестны. Более того, мне неизвестны даже англоязычные книги на эту тему. Ну, кроме собсно ODMG.
Жаль, жаль...
M>>Про "объектную" обертку над реляционными БД (чисто структурная реализация). Пытался реализовать нечто подобное летом. Пробовал на "обертке" решить задачу выборки фирм с телефонами начинающимися с цифр 35 (фирм 20000, телефонов 200000). Результаты впечатлили: Interbase и Oracle (!) упали (уснули и не проснулись). Аналогичное решение на SQL Servere отработало за 0,5 секунды. M>>В чем прикол — до сих пор не понял. S>Скорее всего какой-то стеб с индексами. Если вдруг для этого поля был хеш-индекс, то придется делать scan вместо seek. Хотя даже при table scan несчастные 200 килозаписей не должны смущать приличный сервер.
Да вот же — чушь какая-то. И запросы и структура — абсолютно идентичны. Даже планы исполнения запросов одинаковы. Я даже думал из-за машины. В трех местах проверил — везде так.
Sinclair, скажи пожалуйста, ты на как на вопросы ООБД вышел (из-за чего, кого)? Мне это очень интересно.
Здравствуйте, AndrewVK, Вы писали:
M>>Все это само собой. Но что в блобе то хранится — XML, например? Если так то структура уже не чисто реляционная. AVK>А про чистоту никто и не говорил. Разговор был про применимость.
Ну я про подход спрашивал: то что ты предложил — это гибрид. Согласен — это довольно хорошо работает.
M>>Хмм... Но 3NF там точно не пахло. AVK>А кто сказал что при использовании РСУБД нужна 3НФ?
Нам довольно сильно рекомендовали как наиболее "правильную" и применимую что-ли. Ни подумай ничего такого, слово "денормализация" мне тоже знакомо.
Здравствуйте, Morgun, Вы писали:
M>Sinclair, скажи пожалуйста, ты на как на вопросы ООБД вышел (из-за чего, кого)? Мне это очень интересно.
По историческим причинам. Начал коммерческое программирование с участия в команде разработчиков учетной системы. Парни, не испугавшись, взялись делать ORM. Корявый, медленный, глючный — он даже почти заработал.
С тех пор у меня зреет уверенность, что для успешной разработки приложений автоматизации бизнеса необходимо поддерживать ООП, т.к. в этой отрасли оно самое быстрое. А пропасть между интерфейсом, логикой и хранением меня удручает хуже горькой редьки.
Я хочу получить идеальную систему, в которой разработчик бизнес логики пишет свой кусок кода, размечает его атрибутами, которые сообщают остальной системе необходимую информацию, и инсталляет это в сервер. После чего у всех пользователей сервера сразу доступна расширенная функциональность.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Morgun, Вы писали:
S>Я хочу получить идеальную систему, в которой разработчик бизнес логики пишет свой кусок кода, размечает его атрибутами, которые сообщают остальной системе необходимую информацию, и инсталляет это в сервер. После чего у всех пользователей сервера сразу доступна расширенная функциональность.
Это желание делает тебе честь. Меня тоже удручает наличие указаных тобой "пропастей", хотя мой опыт как прикладного программиста еще не слишком велик.
Буду откровенен — поскольку сегодня меня зачислили в аспирантуру (официально) и мой руководитель (LaptevVV) настаивает на продолжении работ по развитию моего дипломного проекта, у меня появился (кроме практического — документооборот) еще и "чиста научный" интерес к этому вопросу (Напомню тема диплома — обучалка по "Технологии программирования").
Насколько я успел понять — вопрос хранения данных в настоящее время — один из краеугольных вопросов инжинерии ПО. И следовательно он обязательно должен быть хотя бы освящен в рамках диссера по этой тематике.
Больше всего меня огорчает тот факт, что русскоязычного сообщества занимающегося вопросами альтернативных способов хранения данных я не нашел. Может быть его нет в природе?
Кстати Sinclair ты не планируешь заняться этими вопросами с научной точки зрения (в смысле диссер защитить). Я думаю такой человек как ты смог бы — наработки у тебя уже есть.
M>Кстати Sinclair ты не планируешь заняться этими вопросами с научной точки зрения (в смысле диссер защитить). Я думаю такой человек как ты смог бы — наработки у тебя уже есть.
Здравствуйте, mikkri, Вы писали:
M>>Кстати Sinclair ты не планируешь заняться этими вопросами с научной точки зрения (в смысле диссер защитить). Я думаю такой человек как ты смог бы — наработки у тебя уже есть.
M>Звучит!
M>Против Sinclair ничего личного не имею.
Здравствуйте, Morgun, Вы писали: M>Кстати Sinclair ты не планируешь заняться этими вопросами с научной точки зрения (в смысле диссер защитить). Я думаю такой человек как ты смог бы — наработки у тебя уже есть.
Ну вот мне осталось сдать английский язык для официального зачисления в аспирантуру, и ровно этим я и собираюсь заниматься. Собсно, реферат, который ты прочитал, мне пришлось написать при подаче документов в аспирантуру. Там и намечен план работ. Наработок, правда, пока ровно 0 — только вумные мысли. Но уже надо чево-то делать.
Пока не знаю, с какого конца браться:
1. Надо проанализировать существующие системы на предмет отклонения от 11 требований.
2. Скоро до нас должен доехать превью Yukon от MS. Есть мнение, что в него можно запихивать почти произаольный .NET код, что вызывает неудержимое желание набросать маппер из объектной модели в него, который уже будет поддерживать 11 требований.
3. Надо попробовать наколбасить тестовые приложения. Я тут вплотную занялся чтением TPC-C, с целью критически его осмыслить. Уж очень мне подозрительно отсутствие всяких модных кашей в ихних списках. Хочу придумать достаточно компактный тест насчет 11 требований. Пока все как-то смутно.
4. Теория. Читать, читать, и прикидывать, что из теорий применимо.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну вот мне осталось сдать английский язык для официального зачисления в аспирантуру, и ровно этим я и собираюсь заниматься. Собсно, реферат, который ты прочитал, мне пришлось написать при подаче документов в аспирантуру. Там и намечен план работ. Наработок, правда, пока ровно 0 — только вумные мысли. Но уже надо чево-то делать.
Значит коллеги.
Реферат я правда не писал — зачли статью про диплом.Английский сдать не так сложно — мне философия труднее далась (сдал на 5 но попотеть пришлось).
S>Пока не знаю, с какого конца браться: S>1. Надо проанализировать существующие системы на предмет отклонения от 11 требований.
Это обязательно. Но систем ООБД я не много знаю: чаще всего упоминают Cache, O2, Orion. Вживую не видел ни одного.
S>2. Скоро до нас должен доехать превью Yukon от MS. Есть мнение, что в него можно запихивать почти произаольный .NET код, что вызывает неудержимое желание набросать маппер из объектной модели в него, который уже будет поддерживать 11 требований.
Признаюсь о таком услышал впервые — если можно поподробнее. Если можешь дай пару ссылок на описания.
S>3. Надо попробовать наколбасить тестовые приложения. Я тут вплотную занялся чтением TPC-C, с целью критически его осмыслить. Уж очень мне подозрительно отсутствие всяких модных кашей в ихних списках. Хочу придумать достаточно компактный тест насчет 11 требований. Пока все как-то смутно.
Я думаю — для диссера (кандидатского) много приложений не надо. Надо одно, но достойное — желательно с применением к действительно практической задаче. Когда "наколбасишь" много (может быть с помощью своих аспирантов) — можешь докторскую защитить.
S>4. Теория. Читать, читать, и прикидывать, что из теорий применимо.
О теоретических аспектах — упомянуто у C.Кузнецова в статье на CITForumе (там даже ссылки есть). Вопрос был затронут и здесь.
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, Morgun, Вы писали:
M>Вопросы есть, конечно. M>Какую модель представления данных вы использовали?
Собственная разработка, основанная на семантических категориях: Сущность, Объект, Взаимосвязь, Параметр, Значение Признака, Семантическая координата и др...
т.е. при отображении Предметной Области в Модель используются различные способы и средства...
M>Каков характер связки — данные/алгоритмы?
Есть знания о Предметной Области — Модель (это не только данные), а есть
знания как решать задачу — алгоритмические.
В качестве прикладных зыков используется Java, С++ (возможность использования и других языков)
M>В каких предметных областях использовали?
реализованы/реализуются системы:
— Персонал
— АвтоЦетнр (СУП)
— Документооборот
— Ветеринарный контроль
— Сопровождение сложных технических изделий
— Кредитный союз
— Диагностика радиоэлектронной аппаратуры (ОКР)
— Медицинская диагностика (НИР)
M>Удобство разработки?
Разработка ведется на другом уровне
(как факт — небольшой коллектив, а кол-во реализованных систем см. выше)
M>Производительность? M>и т.д. и т.п.
В каких цифрах?
Установите систему и посмотрите сами
M>Если можно — краткое описание системы в электронном виде.
заходите на наш сайт и почитайте там.
(цель сайта другая, но вводные матералы есть)
Здравствуйте, Morgun, Вы писали:
M>Реферат я правда не писал — зачли статью про диплом.Английский сдать не так сложно — мне философия труднее далась (сдал на 5 но попотеть пришлось).
Не, я во-первых физик, а во-вторых — бакалавр выпуска 97го. А философия у нас — халява
S>>1. Надо проанализировать существующие системы на предмет отклонения от 11 требований. M>Это обязательно. Но систем ООБД я не много знаю: чаще всего упоминают Cache, O2, Orion. Вживую не видел ни одного.
Я видел Versant, сейчас стоит свежепоставленный Cache 5.1 single user. Вообще в списке предполагаемых жертв сейчас
M>Признаюсь о таком услышал впервые — если можно поподробнее. Если можешь дай пару ссылок на описания.
Спасибо Мальборо — он рядом положил ссылку.
M>Я думаю — для диссера (кандидатского) много приложений не надо. Надо одно, но достойное — желательно с применением к действительно практической задаче.
Вопрос интересный. Для меня главное — определить место этой технологии среди существующих. А то получается "да здравствует наша ОДБМС — самая быстрая среди нашей ОДБМС!" С этой точки зрения, надо хотя бы один тест провести на поле "хозяев", т.е. RDBMS. Если будет практическое применение, то надо честно показать, чем наша реализация лучше альтернативы (если она, конечно, лучше). С этим вообще беда — мне ни разу не удалось увидеть реализацию коммерческой системы хотя бы на Oracle и MS SQL — чтобы сравнить реальную проихводительность в конкретном случае. Слишком дорого оказывается. А если разрабатывать весь код в "режиме совместимости", то результат получится совершенно нерелевантным. В общем, нужно не просто доказательтво того, что базу Northwind можно наколбасить и в такой системе, а демонстрация преимуществ. M>Когда "наколбасишь" много (может быть с помощью своих аспирантов) — можешь докторскую защитить.
Да тут хотя бы что-то наколбасить... Гульбарий там собрать... А докторский саквояж мне, если чо, друзья купют. M>О теоретических аспектах — упомянуто у C.Кузнецова в статье на CITForumе (там даже ссылки есть). Вопрос был затронут и здесь.
Почитаю. Ты, кстати, кинь прямой линк на статью — а то там Кузнецов-то довольно много чего опубликовал.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я хочу получить идеальную систему, в которой разработчик бизнес логики пишет свой кусок кода, размечает его атрибутами, которые сообщают остальной системе необходимую информацию, и инсталляет это в сервер. После чего у всех пользователей сервера сразу доступна расширенная функциональность.
А чем это будет принципиально отличаться от EJB, если не секрет?
наличие указаных тобой "пропастей", хотя мой опыт как прикладного программиста еще не слишком велик. 
