Вопрос по поводу использования персистентных CORBA и EJB объектов

← →
AnatolyG (2002-03-28 10:31) [0]

А ответьте, пожалуйста, делитанту.

Есть множество объектов предметной области, информация о которых должна храниться в системе постоянно. Если объекты представить персистентными CORBA или EJB объектами, то не появляются ли проблемы с производительностью, когда требуется, например, выбрать по сложным критериям несколько объектов? Т.е. пусть есть задача типа "...дайте мне всех клиентов, которые сделали заказы в апреле прошлого года и в этих заказах содержались медные болты, а средняя сумма заказа в течении года была больше 1000 руб..."
Если у меня и клиенты и товары и заказы - персистентные объекты, то как будет выглядеть код, отбирающий клиентов по такому критерию? Что будет с кодом, если критерий изменится? И какова будет его производительность?
Что-то мне подсказывает, что СУБД и мощь SQL более применимы, а прослойка в виде персистентных CORBA или EJB объектов сводит на нет все преимущества работы с большими объемами данных, даваемыми СУБД (индексирование, кеширование, кластеризация и проч).
Конечно, когда приводится какой-нибудь пример из 10-и Entity-bean объектов "книга" и 3-х "клиентов", то все хорошо. А дальше?

← →
paul_shmakov © (2002-03-28 22:55) [1]

взять тот же ejb, как наиболее развитую компонентную концепцию. персистентность все равно основывается на использовании обычной субд ejb-контейнером. ну а субд применяются обычные и всем знакомые.
все, что делает ejb-контейнер - это скрывает работу с субд от разработчика entitybean-ов. так что, скорость страдать не должна.

← →
AnatolyG (2002-03-29 17:13) [2]

Скорость чего? От разработчика entitybean-ов контейнер скрывает работу только с одной таблицей. Той, в которой хранятся сво-ва этих бинов, с помощью которой, собственно говоря, обеспечивается персистентность. Т.е.:
Один бизнес-объект = Один бин = Одна таблица.
Теперь вернусь к задаче.
Пусть у меня, как у разработчика EJB-клиента есть возможность обращатся к следующим трем классам entitybean-ов: "Клиент", "Товар", "Заказ"
Пусть в системе уже есть 100 клиентов, 56000 наименований товаров, 2300 заказов. В одной книжке по CORBA была глава, в которой говорилось, что распределенные системы могут содержать десятки миллионов объектов. Как в нашем случае будет выглядеть код, отбирающий клиентов по критерию "...дайте мне всех клиентов, которые сделали заказы в апреле прошлого года и в этих заказах содержались медные болты, а средняя сумма заказа в течении года была больше 1000 руб..."? Мне придется последовательно перебирать все объекты, обращаться к ним, для получения их свойств, делать промежуточные расчеты и проч?

Так во что мне обойдется сокрытие СУБД? Или есть какие-то более удачные стратегии разработки entitybean-ов, чем Один бизнес-объект -> Один entitybean?

← →
AnatolyG (2002-04-01 16:49) [3]

Я, конечно, делитант, но не настолько и понимаю, как происходит маппинг и чем отличается CMP от BMP. Это, право, не интересно. Про одну таблицу я сказал условно. :0))
Судя по всему Вы не первый день работаете с этой технологией. Так вот что лучше скажите. Меня интересует вопрос, касающийся принципов распределенной архитектуры, использующей entity-bean-ы. И вопрос (все тот же) простой. Пусть я - разработчик клиента и у меня НЕТ, подчеркиваю, НЕТ доступа к БД. Я не пишу никаких дескрипторов, никакого SQL. Если привести аналогию с семплом от Sun (см. EJB Tutorial) - Duke"s Bank Application, то я пишу JSP, которые обращаются к компонентам EJB. Разработчики среднего слоя, как, вроде, и полагается по идее EJB скрыли всю информацию о предметной области в entity-bean-ах: "Клиент", "Товар", "Заказ".
Пусть в системе уже есть 100 клиентов, 56000 наименований товаров, 2300 заказов (это все entity-bean-ы). Как в таком случае в моей JSP, А НЕ В КАКОМ-ТО СПЕЦИАЛЬНОМ БИНЕ, будет выглядеть код, отбирающий клиентов по критерию "...дайте мне всех клиентов, которые сделали заказы в апреле прошлого года и в этих заказах содержались медные болты, а средняя сумма заказа в течении года была больше 1000 руб..."? Какова будет его производительность, и во что мне обойдется изменение условий (в SQL я просто напишу новый запрос).

У Sun в Duke"s Bank Application информация о клиентах и счетах храниться в entity-bean-ах. Вот я и подумал, а что, если кол-во этих объектов будет велико и потребуется проводить НАД НИМИ (НЕ НАД SQL В БД, т.к. считается, что для того мы и скрыли все в entity-bean-ах, чтобы никогда не возвращаться к БД) сложные операции выборки? На уровне трех опрераций над счетом типа: Получить счет, Добавить на счет, Снять со счета все хорошо даже с 100000 экземплярами счетов. Но если потребуется сделать что-то вроде упомянутого отчета? Что, использовать какие-то вложенные циклы, в которых получать ссылки на объекты, получать их св-ва, производить промежуточные вычисления, т.е. все перебором?
Вот зачем нужны session-bean-ы - это понятно. А зачем скрывать уровень БД, а затем придумывать решение созданных проблем - EJB QL (рекомендую посмотреть) - не понятно.

← →
iZEN (2002-04-01 19:35) [4]

AnatolyG, а как Вы видите решение такой проблемы(обработка сложных выборок)?

← →
paul_shmakov © (2002-04-02 12:43) [5]

2 AnatolyG:
"Я, конечно, делитант, но не настолько и понимаю, как происходит маппинг и чем отличается CMP от BMP. Это, право, не интересно. Про одну таблицу я сказал условно. :0))"
прошу прощения, если чем обидел ;)

"Судя по всему Вы не первый день работаете с этой технологией."
:) я, честно говоря, с ней вообще не работаю :) давно просто очень интересуюсь.

"А зачем скрывать уровень БД, а затем придумывать решение созданных проблем - EJB QL (рекомендую посмотреть) - не понятно."

уровень бд скрывается от клиента, чтобы ограничить действия, которые он может осуществить, имея этот доступ.
если клиент работает с компонентом "банковский счет", то он кроме интерфейса этого компонента ничего видеть не должен! ни в коем разе.
ejb - более высокая абстракция, что очень хорошо. но за более высокие абстракции чем то приходиться платить (я, например, когда в школе еще smalltalk изучал, то мы очень возмущались - что это мол за язык, в который ассемблерные вставки нельзя вставлять). зато какие преимущества!
да, к тому же, данные не обязательно могут храниться в бд. есть пример - вокруг 1С:Предприятие сделали corba-обертку, а еще выше сделали набор компонентов ejb.
но зачем об этом знать клиенту?

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

← →
AnatolyG (2002-04-02 14:19) [6]

2 paul_shmakov

Опять двадцать пять... :0))
Представте, что писать бины я вообще не умею. Я разработчик клиентских приложений. Средний слой мне дали готовый. Разделение труда, специализация. :0) Мастера сокрытия БД скрыли все, дав мне просто кучу объектов "Клиент", "Товар", "Заказ". Вроде это хорошо, полностью соответствует классической концепции использования персистентных объектов для сокрытия БД,
дает возможность реализовавать над этим множеством любые алгоритмы.
Средний слой делали давно и на заказ у сторонней фирмы. То есть о написании каких-то новых бинов, реализующих отчет речи быть не может, да это и не подразумевается классической концепцией использования персистентных объектов для сокрытия БД, в соответствии с которой наши entity-bean-ы "Клиент", "Товар", "Заказ" и есть эта самая БД, хранилище информации о прикладных объекта, из которого мы и должны получать любую интересующую нас информацию.

Были написаны JSP для заказа товаров на складе, для добавления/изменения/удаления товаров и проч. Эти JSP работали с
entity-bean-ами "Клиент", "Товар", "Заказ". И система работает, люди заказывают товары...

Вдруг требуется написать JSP, выдающую отчет "...дайте мне всех клиентов, которые сделали заказы в апреле прошлого года и в этих заказах содержались медные болты, а средняя сумма заказа в течении года была больше 1000 руб..."?
Как я должен написать такую JSP? Повторюсь, J S P !!!Писать вложенные циклы, перебирающие объекты по их ссылкам или воспользоваться EJB QL? Но для такого запроса его мощности последнего маловато?

Тогда может быть сокрытие БД (механизма, великолепно приспособленного для практически любых операций над сложными и большими объемами данных об объектах (SQL, индексирование, кластеризация таблиц и проч)) через entity-bean-ы может создать много проблем и принести только мифические преимущества?

А обертки можно делать не на персистентных объектах, создающих много проблем, а на session-bean-ах. Т.е. делать обертки как функциональные интерфейсы.

← →
А.Цимбал (2002-04-03 10:47) [7]

Добрый день!

Сначала позвольте внести некоторую ясность.
Во-первых, JSP - точно такой же (концептуально) серверный компонент, как и EJB. Разница только в виде контейнера, в котором исполняется и тот, и другой. Поэтому подход "надо написать JSP, а EJB написать в принципе нельзя" выглядит несколько странным. Возможен, конечно, вариант, что программист вообще не имеет доступа к базе данных (и ничего о ней не знает), но тогда при чем здесь SQL?

Во-вторых, не очень понятно, как можно использовать QL, не собираясь при этом писать EJB :). QL существует на уровне entity-компонента в режиме CMP. Клиенту его функциональность доступна только через select-методы.

В общем, если у вас есть только component-интерфейсы компонентов и нет иного доступа к БД, то все равно вы ничего не придумаете, кроме как использовать их, например, в JSP.
Если доступ есть, то действительно проще написать новый компонент, который содержит один или несколько запросов в виде QL. QL совершенно спокойно решает задачу выборки записей по указанным Вами критериям.
Насчет эффективности QL - вопрос сложный. Все зависит от реализации. Поскольку QL-запрос находится в дескрипторе, то контейнер при установке компонента может просто сгенерировать соответствующий SQL-оператор, который потом будет использован в качестве реализации соответствующего select-метода. В этом случае эффективность такого запроса будет очень высока.

И самое главное. Entity-компоненты нужны не для того (точнее, не только для того), чтобы "сокрыть БД". Они нужны для обеспечения большей переносимости и универсальности кода и кеширования данных не на сервере, не на клиенте, а на промежуточном слое (сервере приложений). Если Вам это не нужно, то нет смысла использовать entity-компоненты вообще. По большому счету, это просто удобство. Ну проще моделировать отношение типа один-ко-многим с помощью entity-компонентов, а не "вручную" - для session-компонентов.

С уважением

← →
AnatolyG (2002-04-03 13:03) [8]

to А.Цимбал

В информационных системах есть задача постоянного хранения данных об объектах предметной области. Средства хранения должны предлагать интерфейс для взаимодействия с ними прочих компонентов информационной системы. Я клоню к сравнению эффективности разработки и использования интерфейсов двух средств хранения. Первое - РСУБД, ООРСУБД, ООСУБД с объектными версиями SQL и специализированными языками управления объектами. Второе - СУБД и вызовами EntityBeans. Зачем нам делать ОО представление данных с помощью EntityBeans, если это можно сделать более эффективно с точки зрения производительности с помощью, например, ООСУБД, в большинство которых встроены JVM?

← →
А.Цимбал (2002-04-03 13:19) [9]

Разумеется, объектная СУБД по определению подходит больше, чем EJB/JDBC (т.е. РСУБД). Если у вас есть такая возможность - о чем вопрос?

С уважением

← →
А.Цимбал (2002-04-03 13:48) [10]

В такой постановке воппрос об эффективности - это вопрос выбора конкретного решения для конкретной задачи. Ясно, что концептуально объектные СУБД лучше реляционных, но это только в принципе.
Если можно, как вы пишите, вашу задачу сделать на основе объектной СУБД, то в чем проблема?

С уважением

← →
А.Цимбал (2002-04-03 13:49) [11]

Извиняюсь за повтор - не был уверен, что первый ответ дошел :)

← →
AnatolyG (2002-04-03 15:02) [12]

to А.Цимбал

Хочу поблагодарить Вас за поддержание дискуссии. Мне эта тема насколько неодназначна, настолькл и интересна.
Как Вы думаете, что конкретно может подвинуть разработчика к использованию E-Bs? Чего я могу лишиться при использовании вместо них ООСУБД?

← →
А.Цимбал (2002-04-03 15:21) [13]

JDBC/entity beans - не более, чем попытка автоматической генерации объектного представления данных, которые заведомо хранятся в реляционнов виде. Ну жизнь так устроена - основной массив информации реально хранится именно в РСУБД.
Отвечая на ваш вопрос, скажу так: вы лишитесь возможности использовать уже накопленные ранее данные из РСУБД. Кроме того, вы, возможно, потеряете в эффективности - в том случае, если используемая вами ОСУБД работает медленнее, чем связка SQL-трансформация_реляционного_представления_в_объектное_и_обратно.

В настоящий момент применение entity-компонентов вполне оправданно с точки зрения эффективности - особенно при правильном использования параметров кеша, QL, локальных интерфейсов и сочетания CMP и BMP-режимов.

Конечно, объектное представление данных в элементах распределнной системы идеально сочетается с объектными БД. Но это не единственная область, когда дорога в объезд часто бывает короче прямой.:)

С уважением.

Вопрос по поводу использования персистентных CORBA и EJB объектов Найти похожие ветки