Зачем нужны ejb

 
 
 
Сообщения:360
Привет!

Зачем нужны ejb простым языком?

Читаю туториалы, но когда их использовать и для чего не понимаю.
 
 
Сообщения:586
Вам интересно зачем они придуманы или в чем их преимущество перед другими технологиями?
 
 
Сообщения:360
Зачем они придуманы.
 
 
Сообщения:105
интересная статья от IBM на эту тему:
Вероотступник Geronimo: OpenEJB и реализация EJB в Apache Geronimo

узелки на память:тынцideonewikiARCHjava-tutorialspoint
 
 
Сообщения:360
Спасибо!
 
 
Сообщения:856
samolisov:
Вам интересно зачем они придуманы или в чем их преимущество перед другими технологиями?


а они (эти преимущества) есть ? Знаком с Вашей статьей http://articles.javatalks.ru/articles/24, спасибо, интересно...хотелось бы еще для полной обьективности, сравнение ejb c ... чеб такого заковыристого взять)).ну возмем Play! c Netty.
 
 
Сообщения:586
В своей статье я описывал не столько EJB, сколько промышленные сервера приложений и зачем они нужны. Запускать на них, например на WebSphere AS z/OS, можно и Play! и Spring Framework. Коллеги на прошлом бенчмарке тестировали Vaadin на мейнфрейме. В этот свой первый заезд в клиентский центр в Монпелье я тестирую EJB с Message Driven Beans, JPA (Hibernate) и DB2.

Сравнивать Play! и Netty с EJB - это все равно, что сравнивать теплое и кислое. Одно - это фреймворк для построения GUI и библиотека для организации однопоточного сетевого взаимодействия с помощью мультиплексора, а другое - часть стандарта Java EE, отвечающая за организацию бизнес-логики и предоставляющая декларативное управление безопасностью, долговременным хранением данных, глобальными транзакциями, распределенными объектами, кластеризацией и подпиской на сообщения. Основная задача данного стандарта (EJB): освободить программиста от реализации низкоуровневых вещей, которые я перечислил выше.

Основной альтеративой EJB долгие годы является Spring Framework, который, однако, ни одну из вышеперечисленных задач не решает самостоятельно. Есть отвевления в проекте Spring, отвечающие за модульность (Spring DM), безопасность (Spring Security), но при этом нет реализации SSO (хотя, коллеги поправят, если появилось), нет менеджера глобальных и распределенных транзакций, Spring лишь умеет подключаться к существующим, предоставляемым как правило полноценными серверами приложений. Что касается кластеризации, то она в Spring Framework'е как таковая отсутствует, т.е. можно конечно развернуть две копии приложения на Tomcat, но за репликацию сессий, если таковые используются, будет отвечать сам Tomcat, а за вызов обеих копий по протоколу HTTP - какой-нибудь внешний балансировщик, сам фреймворк при этом не причем. При использовании же EJB мы, во-первых, не привязаны к HTTP-протоколу и внешнему балансировщику, EJB-клиент является сам себе балансировщиком, да к тому же работает по более быстрому протоколу, а, во-вторых, обеспечивается прозрачное для клиента восстановление после сбоев: если вы отметили метод бина как идемпотентный, то клиет (сервлет или RMI/IIOP-клиент) автоматически будет переброшен на экземпляр бина на другом сервере в случае сбоя, тем самым даже не заметив проблемы.

Т.е. Spring Framework выступает топором в одноименной каше: он очень крут, но чтобы решить задачу, нужно сыпануть в варево порцию библиотек, перемешать и молиться, чтобы ничего не сбоило и не конфликтовало друг с другом. JAR-Hell опять же. Ну и таскать ворох библиотек в WEB-INF - удовольствие ниже среднего.

Основным недостатком EJB как правило считают многословность, трудоемкость для разработчика, большие XML-дескрипторы и т.д. Но это все давно в прошлом. Начиная с EJB 3.0, это уже практически новая технология, лаконичная, активно использующая аннотации как средство описания метаданных. Появившиеся в EJB 3.1 и Java EE 6 нововведения делают альтернативные средства, такие как Spring Framework, Google Guice, Tapestry IoC ненужными. Да, когда-то они решали свою задачу: облегчать программисту доступ к низкоуровневым сервисам, минуя EJB, но теперь эта задача не актуальна. У вас из коробки в сервере приложений доступны: IoC-контейнер, менеджер глобальных и распределенных транзакций, декларативные настройки безопасности, огромное количество различных провайдеров безопасности (хранение данных пользователей хоть а LDAP, хоть в БД, хоть в специализированных решениях, авторизация хоть по паролю, хоть по сертификату, контроль сертификатов, цепочки отзыва, Single Sign On (SSO), сквозная по всем приложениям авторизация и аутентификация, когда сервер приложений определяет, имеет ли право пользователь, вошедший по сертификату, писать в очередь A и читать данные из БД под пользователем B, гибкая система прав доступа, когда ровно в 18:00 админ превращается в тыкву и т.д.), полноценная кластеризация, работа с очередями сообщений и внешними информационными системами. И EJB - самый простой с точки зрения программиста способ воспользоваться данным богатством, при этом ваш код будет по прежнему состоять из старых-добрых POJO, использовать JPA или JDBC и вызываться из любого веб-фреймворка, который вам нравится.

Собственно, вот зачем нужны EJB в современном мире разработки корпоративных приложений.
Изменен:29 ноя 2014 05:32
 
Модераторы:frymock
Сейчас эту тему просматривают:Нет