저는 Java EE를 처음 접했고 EJB가 순수 Java/Oracle 커뮤니티 내에 살아 있다는 것을 알게되었습니다. 그러나 누군가 다른 사람이 "EJB"라는 구절을 말할 때마다 직장에서 모두가 싫어하는 표정을 짓습니다. 그래서 나는 그들이 멸종되거나 다른 미들웨어 기술로 현대 개발팀으로 대체되었다고 생각하게 만듭니다.EJB와 Modern Java Development
JSP가 JSF 중심의 뷰 기술로 바뀌었던 것처럼 EJB에도 똑같은가요? 어쨌든, EJB에 대한 대중적인 대안은 무엇이며 어떻게 다른가? EJB를 통해 어떤 이점이나 기능을 제공합니까?
EJB의 첫 번째 버전은 1990 년대 말에 소개되었습니다.
EJB가 언급 될 때 동료 얼굴에 혐오감을주는 모양은 처음 두 버전의 EJB (예 : 복잡한 xml 배포 설명자)의 매우 복잡하고 까다로운 사용 패턴의 결과 일 수 있습니다.
3.0 및 3.1은 사용 편의성이 크게 향상되었습니다.
대중적인 대안은 Spring framework입니다 + 참으로 아주 소수의 사람들이 사용 즐길 부정한 짐승이었다/JPA 동료 앞에서 만 EJB2을 보았고 수도
소개되었을 때 EJB는 문제를 찾아내는 해결책이었습니다.
EJB는 프로그램이 EJB를 "포함"하는 응용 프로그램 서버가로드 균형 조정, 위치 확인, 장애 극복, 보안 등과 같이 더 어려운 모든 비트를 처리 할 수 있도록 작업 단위를 정의하는 방법을 제공합니다. 리모팅 등. 실제로, 개발자가 모두 반짝 반짝 빛나는 새로운 언어로 해고 당했을 때, 구현은 모든 과중한 작업을 위해 실제로 준비되지 않았고, 기능을 설명했을 수도 있지만 구성과 배포는 확실히 악몽이었습니다. EJB 스펙이 그동안 유동적이었던 것을 돕지 못했고 주요 유스 케이스 후보 인 Entity Bean의 성능이 심각하게 부족했습니다.
필자는 항상 일괄 처리를 처리하는 EJB를 개발했습니다. 하루에 한 번 트랜잭션 집합을 가져오고 일부 데이터베이스 작업을 수행 한 다음 출력을 다양한 이해 관계자에게 보내고 보고서를 생성합니다. 다른 EJB 기능 대부분은 말할 것도없고 스레딩이나로드 균형 조정이 필요하지 않았습니다. 가장 많이 사용 된 것은 응용 프로그램에 대한 웹 중심 접근 방식이었습니다. Whold 응용 프로그램은 일부 배치 작업과 몇 개의 웹 페이지에서 수행 될 수있었습니다.
나는 EJB의 명시된 원래 목적이 분산 컴포넌트 모델을 제공한다는 것을 기억한다. 공급 업체의 마켓 플레이스 구성 요소. 예 : 세금 계산 구성 요소.이 아이디어는 결코 사라지지 않았지만, 초기 기술에서는 많은 방향으로 보였으므로, '빈 전개 자'는 (닫힌 소스) 빈을 사용자 환경에 맞게 사용자 정의하여 여전히이 아이디어를 암시 할 수 있습니다. –
EJB2에서는 개발자가 구현을 제공해야하지만 개발자가 (비즈니스) 목표와 관련이없는 미친 수명주기 방법으로 매우 침입적인 프레임 워크 제공 인터페이스를 구현해야만했습니다. 개발자의 그러한 인공물 중 몇 가지는 제공되어야했습니다.
또한 모든 빈은 매우 자세하고 읽기 어려운 배포 설명자 (XML 파일)의 항목과 동기화되어야합니다. 마치 개발자에게 모욕적이지 않은 것처럼, 빈을 '강화'하고 프록시 클래스, 스켈레톤 및 스텁을 생성하기 위해 특수 도구를 사용해야했습니다. 상속과 같은 일반적인 OO는 지원되지 않았습니다. 일종의 주사가 있었지만, 각 콩과 관련된 일종의지도 (실제로는 디렉토리)에 물건을 넣는 것에서 생긴 이상한 것이있었습니다.
원래 EJB 1 모델은 모든 통신을 원격으로하고 모든 객체를 배포하도록 강제했습니다 (원래 EJB는 원격 기술로만 간주되었습니다).따라서 EJB의 이점을 얻으려면 완전히 불필요한 경우에도 아키텍처를 분산시켜야합니다.
아마 가장 큰 모욕은 Entity Bean의 개념입니다 (JPA 엔티티와 혼동해서는 안 됨). 이 유형의 빈에 대한 결함은 너무 커서 그 당시 EJB의 가장 큰 지지자조차도 거의 누구에게도 추천 할 수 없었습니다.
그런데 매우 실용적인 문제로, EJB 구현 간의 호환성은 그다지 말할 것도 없었습니다. 특히 엔티티 빈은 대량의 공급 업체 특정 구성을 필요로합니다.
EJB를 구현하려면 폐쇄 된 소스이며 다소 비싸기 때문에 (설치 크기와 필요한 메모리면에서) 많은 애플리케이션 서버가 필요했습니다. 따라서 투자를 먼저 지불해야했기 때문에 회사가 업그레이드 또는 전환 할 수 없습니다 뒤로). 당시 많은 사람들이이 기술에 대해 블로그를 작성한 것을 기억하지 못합니다. 기술이 영업 팀에 의해 대부분 대기업 관리자에게 전달되었다는 것을 기억합니다.
이 기술이 일반 개발자에게 실제로 사랑받지 못했다는 것은 놀라운 일이 아닙니다.
Sun은이 기술이 완전히 잘못된 방향으로 가고 있으며 180 ° 회전하여 대규모 엔지니어링 작업을 시작했다고 알고 있습니다.
결과적으로 EJB 3 (2006)은 매우 가볍고 가벼운 접근 방식입니다. 구현할 필요가있는 프레임 워크 인터페이스는 없으며 필수 XML은 없다. 하나의 빈 만 코딩하면된다. (간단한 POJO 만) 모든 곳에서 정상적인 기본 설정이있다. do), 그리고 간단한 bean을 로컬에서 사용하는 것은 실제로 현재 흔히 일어나는 일이다.
엔티티 빈은 너무 결함이있어서 완전히 삭제되었으며 TopLink와 Hibernate가 옹호하는 훨씬 건전한 접근 방식으로 대체되었습니다.
기술을 옹호하는 많은 유명 블로거 (예 : Adam Bien, Rezha Rahman, Gavin King)와 결합하여 자유롭고 가벼운 오픈 소스 구현의 광범위한 가용성과 결합하여 인기를 다시 얻는 것이 설명하기 쉽습니다 .
최근에 발표 된 "Spring to Java EE"마이그레이션 가이드가 많이 있었으며 많은 사람들이 EJB에 대한 지원이 매우 우수한 기술임을 보여주는 다양한 뉴스 사이트에서 매우 유리한 표를 얻었습니다 . 이것은 반세기 전에는 생각할 수 없었을 것입니다 (EJB 3가 출시되었을 때 아직 알려지지 않았을 때).
EJB의 가장 일반적인 대안은 스프링 코어 (Spring Beans)입니다. 현재로서는 Spring이 EJB와 다른면에서 큰 장점이 없다고 생각합니다. 두 기술은 매우 유사합니다. Spring은 좀 더 편리한 유틸리티를 제공하는 반면, EJB는 개념적으로 더 가볍습니다 (XML이 없음). 두 장점 모두 다소 주관적입니다. 그들은 일반적으로 서로의 기능에 영감을 얻었으며 어떤 기술은 어떤 새로운 기술을 마지막으로 출시했는지에 따라 약간 앞 당깁니다.
비슷한 질문이 이전에 여기에 제기되었습니다. 다음 질문을 확인하십시오 : [what-use-are-ejbs] (http://stackoverflow.com/questions/5579890/what-use-are-ejbs), [in-what-situations-are-ejbs-used] (http://stackoverflow.com/questions/4773927/in-what-situations-are-ejbs-used-are-they-required-in-websites-web-applicatio) 및 [spring-vs-ejb] (http : //stackoverflow.com/questions/1779169/spring-vs-ejb-can-spring-replace-ejb) – CoolBeans