Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 EJB  [new]
Jen
Guest
Интересно, если необходимо создать систему автоматизации со сложными алгоритмами обработки данных, клиентский доступ будет состоять на 80 процентов из GUI форм, и на 20 нужен web интерфейс. Есть пара вопросов:
1. Насколько реально использовать для создания GUI EJB, долго получается, намного проще взять компоненты от JBuilder, а не через вызовы меотдов EJB.
2. Скорость написания алгоримов обработки данных наверное намного быстрее работает если это серверные языки (T-SQL, PL/SQL), а не Java. А по основам EJB логику надо выносить на средний слой (хотя никто не мешает оставить ее на сервере).
У кого какие мнения по вопросам ?
30 янв 04, 14:35    [514712]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6810
По второму вопросу - во всём нужно знать меру. Операции, связанные с обработкой больших объёмов данных, эффективнее выполнять в СУБД, а не такскать резалтсеты туда-сюда. Более того, как показывает практика, такие операции отлично оформляются процедурным образом, и особого выигрыша с использованием ООП нет.

Разумеется, сразу же следует отказаться от Entity Beans.
30 янв 04, 18:58    [515347]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Maxel
Member

Откуда:
Сообщений: 38
>> Разумеется, сразу же следует отказаться от Entity Beans

Разумеется ни в коем случае не стоит отказываться от EntityBeans. Если все грамотно прописать в дескрипторах, то контейнер будет кэшировать EntityBeans и приложение будет просто летать по сравнению с тупым доступом через ResultSet-ы.
Далее. Если приложение подразумевает какое-то дальнейшее развитие, то использование выделенной бизнес-логики более чем оправданно, так как при грамотном проектировании создается огромное поле для повторного использования ранее созданных вещей. Следовательно будет гораздо меньше головняков.
Средний слой в терминах EJB подразумевает, что контейнер делает всю муторную работу по обслуживанию транзакций и безопасности. Если в Вашем приложении эти моменты не особо критичны, то нет смысла связываться с EJB - трудоемкость создания таких приложений прямо скажем повыше. Хотя при должном опыте развертывание EJB приложений делается довольно-таки быстро.
2 фев 04, 08:53    [516412]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6810
Разумеется, с использованием полноценной СУБД не стоит плодить схемы с двойным, тройным и т.д. кэшированием данных - это не только бесполезно (механизмы кэширования данных в таких СУБД гораздо мощнее, чем то, что предлагается EJB-контейнерами), но и вредно, поскольку создаёт дополнительную вычислительную нагрузку. К тому же, встаёт вопрос согласования кэшей данных аппсервера и СУБД - при изменении строки в кэше СУБД необходимо каким-то образом информировать об этом аппсервер, а такой механизм, будучи реализован, может создавать некислый сетевой трафик, не говоря уже о сложности, ненадёжности и, опять же, дополнительных вычислительных затратах для его функционирования... Это было объективное мнение. Субъективное - работать с данными проще и эффективнее с использованием SQL, а не объектных методов.

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


А что, собственно, мешает логику держать в СУБД или смешивать СУБД и аппсервер? С точки зрения повторного использования готового функционала это ничуть не сложнее.
2 фев 04, 10:48    [516565]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
andy753
Member

Откуда: Moscow
Сообщений: 371
To ScottTiger:
Позвольте не согласится со столь уж категоричными суждениями :). Все сильно зависити и от задачи и от варианта реализации ее. Приведу несколько простых примеров:
1. В некой таблице находятся относительно статичные данные, тогда реализация через кэш и с довольно боьлшим пулом компонент позволит вам практически нивелировать нагрузку на сервер СУБД. Обычно сервера EJB позволяют такие вещи хорошо масштабировать нагрузку как покомпонентно так и кластеризовать сервер. Аналогичный фокус через СУБД - дорого Вам обойдется. Нагрузка на сервер будет расти пропорционально (если не больше) числу одновременных запросов.

В сильно модифицированной таблице - это конечно не пройдет :)

2. StateFull компонента может быть ориентированан не на клиента, а на объекты. Тогда Одна компонента может держать на себе все изменения таблицы и обмениваться информацией с клиентами минуя дополнительные запросы на сервер СУБД. Простейший пример: таблица курсов валют :)

Никогда не задумывались, почему сервера приложений получили такое распространение. Во всяком случае, не за сверх геморрой, связанный с разработкой промежуточного уровня (уж извините меня за выражение). А именно за более простую, удобную и гораздо дешевую схему масштабирования задачи. Понятно, что это относится к определенному классу задач. Согласен, что это не универсальный, а узкоспециализированный инструмент. Даже спорить не буду. Но в ряде случаев стандартный клиент-сервер просто загнется там где работает 3-х звенка :).
2 фев 04, 13:38    [517007]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Jen
Guest
Извините что перебиваю, но есть еще и второй вопрос (точнее первый). Нам необходимо создать приложение. Большая часть данных будет обрабатываться в локальной сети, посредством GUI форм, остальная часть через "инет", то есть web доступ. Приложенеие основано на более чем 150 таблицах. ДЛя web части проще всего создать бизнес слой. Но для GUI придется либо просто напрямую соединяться к БД, либо через бизнес слой, но я нигде не могу найти как например взаимодействовать с JTable. Может ли кто помочь с документаций построения приложений EJB+GUI, и вообще стоит ли.
2 фев 04, 14:16    [517088]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6810
2andy753: я не поклонник двузвенки, даже противник, но EJB "не торкает" :) Отвечу по пунктам и добавлю ещё чуть своих рассуждений:

1. Минус моего подхода - меньшая скорость работы сети (соединение между СУБД и аппсервером) относительно доступа к данным, уже находящимся в памяти аппсервера, и соответствующие издержки на выполнение запросов, впрочем, на нормальной технике и ОС сочесть СУБД и аппсервер в рамках одного экземпляра ОС вполне возможно без ущерба для производительности обоих. СУБД - отнюдь не узкое место, более того, поддающееся заметно более гибкой настройке, чем типичный аппсервер (работал с JBoss, немного ковырялся с WebLogic). А вот как гарантировать консистентность данных, если стороннее приложение работает с ними одновременно с каким-то бином? В рамках СУБД есть механизм транзакций, позволяющий с тем или иным успехом :) разрешать такие конфликты, но этот механизм работает только в рамках подключенных к СУБД клиентов, а не мимикрирующих под них интеллектуальне кэши

2. Опять же, как согласовывать данные в кэше аппсервера и в СУБД?

Ещё замечу, что система безопасности в EJB не гибка, недостаточно функциональна в некоторых случаях, а сама технология крайне неудобна при написании клиентской части не на Java. Тяжело использовать EJB-сервера в зафаерволленных сетях - туннелирование RMI-IIOP через, например, HTTP, требует определённых ресурсов и, насколько я знаю, возможно не во всех серверах. Всё это вынудило меня отказаться от дальнейшего использования EJB, и для разрабатываемой сейчас достаточно сложной 3-звенной системы написан собственный аппсервер. Общение клиентской части и среднего звена происходит по завёрнутому в SSL (безопасность на уровне сети) и сжимаемому (уменьшение трафика) достаточно простому (почти голый текст) протоколу. Безопасность (весьма замороченная модель) внутри приложения обеспечивается аппсервером. Бизнес-логика - частично в аппсервере, частично - в СУБД (Oracle).
2 фев 04, 16:01    [517426]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
stdio
Member

Откуда:
Сообщений: 4524
2Scott Tiger:
Ну завернул. ;-)
В принципе, согласен.
2 фев 04, 16:26    [517497]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
andy753
Member

Откуда: Moscow
Сообщений: 371
Я не склонен бицепсы сравнивать :)
Работаю сам с Ягуаром. И общался довольно тесно с ребятами, которые кластер в сбере ставили. Про оракл ничего плохого не скажу, там его не было. Но мелкомягкий под нагрузкой дох как муха (а железка там стояла хорошая). Так вот 10 писюков (ну только памяти стояло кажется гиг) - кластер из ягуаров вполне исправило ситуацию. Все это работает щас под тем же серваком.

Еще раз хочу подчеркнуть одну ну ОЧЕНЬ ПРОСТУЮ мысль. Все отталкивается от задачи и тех ограничений, что ВЫ САМИ (или не вы) создали. А уж дальше надо смотреть и выбирать наиболее подходящий вариант решения. А пытаться решать все задачи с помощью Оракла или EJB - это глупость или дибилизм.

А насчет кэшей и их синхронизации, скажу так. Иногда были задачи, когда лишняя работа по синхронизации окупалась сторицей. Иногда это действительно блажь. Аргументы смотри выше :)
3 фев 04, 10:26    [518204]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6810
Кто такой ягуар? И под какой нагрузкой "дох" MSSQL?

andy753
А пытаться решать все задачи с помощью Оракла или EJB - это глупость или дибилизм.


А кто-то спорит? Хотя, на типичных задачах использовать СУБД, отличную от Oracle, с моей точки зрения, не имеет смысла :) Впрочем, не буду ни с кем дискутировать по этому вопросу.

andy753
Иногда были задачи, когда лишняя работа по синхронизации окупалась сторицей.


Было бы любопытно увидеть/пощупать или почитать технический документ о реально работающих решениях вопроса синхронизации кэша аппсервера с меняющимися в СУБД данными.
3 фев 04, 10:42    [518238]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Ggg
Guest
2 Scott Tiger :
Ягуар - это сервер приложений пр-ва Sybase (старое название). Сейчас он называется Sybase EAS (enterprise application server). Но по привычке все его называют Ягуар.
3 фев 04, 15:25    [519045]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
andy753
Member

Откуда: Moscow
Сообщений: 371
Я не понимаю слова - типичная задача. Дайте определение плиз. Потому как для ораклиста или фокс-прошника (сори за такое именование) они почему то разные. Это легко понять, почитав два форума :)

Насколько помню, около 400 одновременных коннектов. Их коннектов. Только позволю себе напомнить, что коннекты разные бывают. Да легко, простого примера хватит?

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

Дальше можно наворачивать компонент по изменению курсов (к нему доступ обычно авторизован и более редкий чем на чтение). Он может посылать уведомления на ретрив, в этом случае можно убрать ретрив по часам. Правда тут вылезает ограничение - изменение только через эту компоненту. Ну и так далее...
Какие вопросы?
4 фев 04, 10:11    [519939]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6810
ОК, в рамках предложенной задачи:

таблица курсов пополняется/изменяется в СУБД репликацией из какого-то удалённого источника. Допустим, в 10:41:25 приходит реплика, в которой указано, что с 10:46:01 курс, например, доллара США к рублю меняется на полкопейки в ту или иную сторону. Каким образом мне уведомить компонент о произошедшем изменении данных, если он проверяет их 1 раз в час? А если изменения приходят 1 раз в секунду? 50 раз в секунду? 500? Или за 1 секунду до начала действия нового курса? Нет возможности изменять данные только через специальную компоненту. И, скажем прямо, это не курсы валют, а телеметрия

Ничто не мешает из того же веба одновременно 400 пользователям получать доступ к данным в СУБД, если JSP, например, будет выполнять SQL-запрос к СУБД. Данные таблицы - уже давно в кэше буферов, план выполнения запроса - в библиотечном кэше, данные словаря для таблиц(ы) - в словарном кэше (используем терминологию Oracle): в процессе получения данных ни одного обращения к жёстким дискам не будет. Для одновременного выполнения запроса 400 пользователей нужно будет 400 сессий с БД, которые, впрочем, можно (и нужно) открыть загодя. Впрочем, и для получения из аппсервера четырьмя тысячами пользователей одновременно этих данных JVM нужно будет создать 400 потоков.

Не нужно думать, что СУБД - это такой тормозной чёрный ящик. Это далеко не так. Промышленная СУБД - сложный и мощный механизм с продуманными механизмами обеспечения масштабируемости, производительности и максимальной надёжности. 400 коннектов к СУБД - это несерьёзно.

Про типичные задачи - они везде одинаково типичные или атипичные. У меня такая логика - систему такого масштаба, которую можно реализовать на FoxPro, можно реализовать на Oracle, а если можно - значит так и надо делать, потому что Oracle - лучший продукт на рынке СУБД. Впрочем, я обещал не дискутировать по этому вопросу :)
4 фев 04, 11:05    [520124]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
softy
Member

Откуда: from Russia
Сообщений: 5913
to Jen:

Ни в коем случае не пишите сам интерфейс на Java!!!

Пожалейте пользователей.

Только HTML, JavaScript (или другие ...Script).
4 фев 04, 12:07    [520312]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
andy753
Member

Откуда: Moscow
Сообщений: 371
Разумно :) я согласен с softbuilder@inbox.ru
4 фев 04, 12:09    [520316]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
mega_guest
Member

Откуда:
Сообщений: 68
Можно поподробнее, почему ненадо интерфейс на java делать?
У нас планируется новый проект, так мы пока решили делать его полностью на java
5 фев 04, 05:00    [521631]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6810
А потому, что есть тенденция к тому, что Swing-приклады тормозят и раздражают этим пользователя. Меня вот, например, просто из себя выводит, если менюшка появляется не абсолютно моментально, а с задержкой в несколько десятков миллисекунд. Впрочем, я известный извращенец.
5 фев 04, 10:37    [521888]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
andy753
Member

Откуда: Moscow
Сообщений: 371
Я не большой специалист в клиентах на Java. Видел ряд небольших проектов весьма достойных как клиент. Делал сам небольшие проекты. Но все же в целом, в массе - клиенты на Java не вписываются в понятие "удобного интерфейса". Чесно говоря - не видел ни одной информационной системы с хорошим клиентом на Java.

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

Пока с уверенностью могу заявить следующее - если вы не профи по оптимизации клиентов Java, то вряд ли у вас получится сделать удобного клиента на нем. На С++ возможно, на Делфи и Повер Билдере - верю и еще много на чем... А вот на Java - вряд ли.

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

Но вот использование Java на серверной стороне - лично мне импонирует. Есть основания так делать и мы активно сами работаем в этом направлении.
5 фев 04, 11:13    [521998]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
mega_guest
Member

Откуда:
Сообщений: 68
Да, действительно, технологии java изучаю недавно, просмотрев некоторые форумы сложилось впечатление что GUI на java делают очень мало, и ругают за медлительность. Хотя подозреваю что "там" (на западе) наверно клиентов делают и немало. В нашем проекте попробуем сделать пилотного клиента все таки на java.
5 фев 04, 13:21    [522320]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Jen
Guest
Все таки я думаю классные GUI на Java есть. Просто то ли никто не создает их то ли литературы нет. Например Oracle, конечно понимаю, что они пишут свои компоненты. Просто нет готовых компонентов, с которыми можно быстро разрабатывать. Хотя буду бладгодарен за любые советы по совмещению GUI и EJB. Ведь все таки с помощью GUI можно создать более наглядные и простые, да и разрабатывать быстрее интерфейсы к данным. Вот в чем мой вопрос был. Странно что никто не пробовал сделать.
5 фев 04, 15:11    [522639]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
big_mammoth
Member

Откуда: Москва
Сообщений: 85
Scott Tiger
Опять же, как согласовывать данные в кэше аппсервера и в СУБД?



Для этого спецификацией EJB 2.0 предусмотрены для Entity EJB т.н. "commit options"
(Option A, Option B, Option C).

Option A подразумевает что контейнер имеет монопольный доступ (иммется в виду что доступ к таблице осуществляется только через EJB) и в этом случае возникнет ситуация о которой Вы говорите.

Если используется Option B то при начале новой транзакции контейнер синхронизирует Entity EJB с тем что хранится в БД (вызывает ejbLoad)

Option C - контейнер не кеширует экземпляры EJB, после того как Entity EJB был использован он деактивируется
6 фев 04, 12:00    [524060]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6810
А какой тогда смысл в кэше бинов, если в любом реальном случае (B,C) идёт обращение к СУБД?
6 фев 04, 14:20    [524478]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
big_mammoth
Member

Откуда: Москва
Сообщений: 85
для опции B
ну как минимум не тратится время на создание экземпляра, и на активацию
для опции С надо создать новый экземпляр, активировать его и загрузить данные - т.е это самый поганый вариант. На стр 212 рекомендация есть диаграмма на которой показна разница

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

Видимо это оказался единственный платформо независимый метод синхронизации данных.

Cамое поскудное в этой истории что не все EJB контейнеры это дело поддерживают. В стандартном дескрипторе поставки эти настройки не задаются, а задаются в дескрипторе от производителя (jboss-cmp.xml ими ejb-borland.xml) к сожалению я работал только с BES 5.2 - там это есть.
6 фев 04, 15:55    [524692]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
mega_guest
Member

Откуда:
Сообщений: 68
После просмотров многих форумов, складывается впечатление, что EJB "заточено" для использования в интернете (к вопросу о GUI), а если делать GUI к EJB на чем то другом (например на Delphi), то это только через CORBA (что достаточно нетривиально). Хотя старнно что SUN не упрастила доступ к EJB например для языков C/C++, а то получается, что если хотим использовать EJB и WEB интерфесй ненужен, то для более "легкой" интеграции GUI и EJB приходится выбирать Java/Swing. Хотя возможно я и ошибаюсь.
9 фев 04, 05:10    [526414]     Ответить | Цитировать Сообщить модератору
 Re: EJB  [new]
andy753
Member

Откуда: Moscow
Сообщений: 371
Еще как ошибаетесь. Не буду говорить за все среды, сам пишу клиентов на PowerBuilder. Там доступ к EJB довольно прост. Насколько знаю, у борландовских сред тоже нет особых проблем.

EJB также неплохо подходит для Инета, правда куча-мала нехорошая получается - не менее 3-х языков. Вот что противно (Java для EJB, JSP(ASP&Dynamo) для серверных скриптов, JavaScript (VBScript) - для клиента). Можно конечно отказаться от JSP и писать сразу сервлеты, но нам например это не подходит. Плюс уж не забудьте еще SQL :)) В итоге - большая каша получается
9 фев 04, 10:00    [526559]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Java Ответить