728x90
🖐 들어가기 전에
EJB(Enterprise Java Beans)를 공부하기 전에 먼저 Java Beans에 대해 간단하게 알아보자
🥜 Java Bean(자바 빈)
- Java Bean이란 Java로 작성된 소프트웨어 컴포넌트를 말한다
- Java는 프로그램 기본 단위가 클래스이고, Java Bean은 그 클래스들이 복합적으로 이루어진 구조를 말한다
- Java Bean은 데이터를 표현하는 것을 목적으로 하는 자바 클래스로, 컴포넌트와 비슷한 의미로도 사용된다
- Java Bean은 단순히 Java 언어로 작성된 클래스를 의미하는 것이 아니라, 아래의 규격에 따라 만들어진 클래스를 의미한다
Java Bean의 규격
- 클래스는 패키지화 해야 한다
- 멤버 변수는 프로퍼티(Property)라 칭한다
- 클래스는 필요에 따라 직렬화가 가능하다
- 프로퍼티의 접근자는 private이다
- 프로퍼티마다 getter/setter가 존재해야 하며, 그 이름은 각각 get/set으로 시작해야 한다
- 위의 프로퍼티 getter/setter 메서드의 접근자는 public이어야 한다
- 외부에서 프로퍼티에 접근은 메서드를 통해서만 한다
- 프로퍼티는 반드시 읽기/쓰기가 가능해야 하지만, 읽기 전용인 경우 getter만 정의 가능하다
- getter의 경우 파라미터가 존재하지 않아야 하고, setter의 경우 한 개 이상의 파라미터가 존재한다
- 프로퍼티의 type이 boolean인 경우 get 메서드 대신 is 메서드를 사용해도 된다
🔖 EJB (Enterprise Java Beans)
- 기업환경의 시스템을 구현하기 위한 서버 측 컴포넌트 모델이다
- EJB는 애플리케이션 업무 로직을 갖고 있는 서버 애플리케이션이다
- EJB는 비즈니스 객체들을 관리하는 컨테이너 기술, 설정에 의한 트랜잭션 기술 등이 담겨 있었다
- 2000년대 초반에는 EJB라는 개념이 획기적이었고, Java 진영에서 표준으로 인정한 기술이기 때문에 많이 사용되었다
💡 EJB vs Java Bean
- 둘은 용어가 비슷하고 Sun에서 만든 것은 같으나, 만들어진 목적이 다르고 주로 동작하는 위치도 다르다
- Java Bean은 비주얼 개발환경에서 사용되는 재사용 가능한 컴포넌트이며, EJB는 서버 쪽 비즈니스 애플리케이션에 사용되는 분산 객체 컴포넌트 모델이다
- 또한 EJB는 오직 서버에서만 동작하지만, Java Bean은 클라이언트에서 서버로 통신하는 경로에서 사용된다
EJB의 등장
- 기업의 IT 시스템 규모가 점점 커지고 복잡성 또한 증가하면서 많은 사용자들의 요구를 빠르고 안정적이게 처리하기 위한 다양한 기술 (트랜잭션, 멀티 쓰레딩, 리소스 풀링, 보안 등)이 요구되기 시작했따
- 하지만 애플리케이션 개발자가 비즈니스 로직 뿐만 아니라 위에 언급한 기술들을 모두 고려하여 개발하기는 쉽지 않다
- 이를 해결하지 위해 등장한 기술이 바로 EJB이다
- EJB는 구조가 복잡한 대규모 시스템의 분산 객체 환경을 쉽게 구현하기 위해 등장하였다
- EJB의 등장 이후 EJB 1.0의 스펙이 제시한 EJB의 비전은 다음과 같다
EJB는 애플리케이션 개발을 쉽게 만들어준다
애플리케이션 개발자는 로우 레벨의 기술들에 관심을 가질 필요도 없다
- 즉, EJB를 사용하면 개발자들은 도메인과 비즈니스 로직에만 집중하면 된다는 것이었다
- EJB는 독립적으로 개발한 컴포넌트들을 서버에 자유롭게 배포하고 서로 연동해 사용하게 하는 컴포넌트 기반의 개발 모델을 제시한다
EJB의 구조
- 본격적으로 EJB는 거대 규모 시스템 구축을 위한 컴포넌트 모델이다
- 이 때 컴포넌트 모델이란, 대략 각각의 소프트웨어를 독립적인 모듈로 제작하여 재사용과 호환성을 높이는 개념이다
- 일반적으로 사용되는 Jaa EE의 API로 클라이언트가 볼 수 있는 화면단 로직은 JSP가, 비즈니스 로직은 EJB가 구현하는 구조로 구성되어 있다
- 또한 비즈니스 로직을 구현한 것을 Enterprise Bean이라고 부르며 Database 처리, Transaction 처리와 같은 시스템 서비스를 구현한 부분을 컨테이너라고 부른다
- EJB는 크게 Enterprise Bean, Container, EJB Server, Client application으로 구성된다
1) Enterprise Bean
- 비즈니스 로직을 실행하는 서버 컴포넌트로, 보통 2-3가지의 모델을 갖는다
- Session Bean (세션 빈)
- DB 연동 없이 구동이 가능하다
- 주로 로직이 위치한다
- Entity Bean (엔티티 빈)
- 데이터베이스의 데이터 I/O 전반을 관리하는 객체
- select, insert, update, delete 를 수행한다
- DB 관련 쿼리는 자동으로 만들어지고 개발자는 고급 업무 처리에 집중할 수 있다
- DB가 수정되면 코드 수정 없이 다시 배포가 가능하다
- 클라이언트가 Session Bean을 호출하고 Session Bean이 Entity Bean을 호출하며 데이터베이스에 접근하는 구조이다
- Message-driven Bean (메시지 구동 빈)
- JMS로 빈을 날려준다
2) Container
- EJB 컨테이너는 Application Server 내에서 Enterprise Bean에 대한 런타임 환경을 제공한다
- 일반적으로 EJB와 Enterprise Bean 사이에 통신을 하게 해주는 역할을 한다고 이해할 수 있다
- Servlet이 Apache Tomcat과 같은 Servlet Container에 올려서 서비스 되는 것처럼, EJB는 Weblogic, JBoss와 같은 EJB Container에 올려서 서비스 된다
- 보통 사용자는 클라이언트 어플리케이션을 사용하고, 이는 컨테이너를 경유해서 Enterprise Bean에 접근한다
- 컨테이너가 데이터베이스 처리와 트랜잭션 처리 등을 숨기기 위해 개발자와 그것들을 의미하지 않는 어플리케이션을 개발하는 것이 가능하다
- EJB 컨테이너는 Enterprise Bean에 다음과 같은 서비스를 제공한다
- 필요 시 트랜잭션 시작 -> commit 또는 roll back
- 수신 요청에 대해 Enterprise Bean 인스턴스 풀을 준비 상태로 유지 보수 및 비활성 풀과 활성 상태 간 인스턴스 이동
- Bean 내의 스레드 조건 충족 보장
- Entity Bean의 인스턴스 변수와 지속 스토리지에 저장된 해당 데이터 항목의 자동 동기화
3) EJB Server
- EJB Server는 컨테이너를 관리해서 EJB로서 필요한 시스템 서비스(데이터 베이스 처리, 트랜잭션 처리 등)를 구현한다
4) Client Application
- EJB 구조를 사용함에 있어 이와 연결할 수 있는 클라이언트 단의 어플리케이션
- 종류로는 Java Applet, Java Application, Servlet, Java Server Pages(JSP) 가 있다
EJB의 특징
- 인스턴스 풀링
- 객체를 미리 생성하고 메모리에 저장하여 사용 준비 상태에서 서버가 동작한다
- 많은 동시 접속자에 대한 안정성을 지원한다
- 트랜잭션 처리
- 컨테이너가 자동으로 모든 메소드에 대한 트랜잭션 처리를 한다
- 안정적인 데이터 조작이 가능하다
- 퍼시스턴스 관리
- 빈즈의 상태를 메모리에서 사용여부에 따라 자동으로 활성화/비활성화를 관리해준다
- Fat Client를 Thin Client로 n-Tier 시스템을 구축할 수 있다
- EJB 컴포넌트들이 Loading되어 활동하는 서버 쪽 프로그램, 컴포넌트 생성 및 소멸, 라이프 사이클 보안, Threading 등의 서비스를 제공해준다
- 분산 기능을 지원한다
- Weblogic, Websperer을 주로 사용하며, 국산은 제우스(jeus)를 사용한다
EJB의 한계
- 성능적 측면
- EJB에서는 현실에서 1% 미만의 애플리케이션에서만 필요한 분산 트랜잭션을 위해 나머지 99%의 애플리케이션도 무거운 JTA 기반의 글로벌 트랜잭션 관리 기능을 사용해야 했다
- 즉, 특정 환경 및 기술에 종속적인 코드이다
- 또한 EJB 컴포넌트는 컨테이너 밖에서는 정상적으로 동작할 수 없으므로 개발자들은 끝도 없이 반복되는 수정-빌드-배포-테스트의 과정으로 많은 시간을 낭비해야 했고, 간단한 기능에 대해서 조차 자동화된 테스트를 만드는 것은 거의 불가능했다
- EJB는 분산 환경을 지원하기 위해 객체를 직렬화하는 과정에서 실행 속도의 저하가 발생한다
- 이러한 EJB의 원격 분산 모델은 시스템의 성능을 떨어뜨리고 서버의 복잡도만 증가시켰다
- 비용적 측면
- 게다가 EJB의 혜택을 얻기 위해 모든 기능이 다 필요하지도 않은 고가의 WAS를 구입해야 했고, 고급 IDE의 도움 없이 는 손쉽게 다룰 수 없는 복잡한 설정 파일 또한 필요했다
- EJB의 가장 큰 문제점은 EJB 스펙을 따르는 비즈니스 오브젝트들은 객체지향적인 특징과 장점을 포기해야 했다는 것이다
- 결국 EJB는 낮은 생산성, 느린 성능, 불필요한 기술 복잡도 등으로 인해 자바의 엔터프이즈 개발에 대한 불신을 가중시켰다
POJO의 등장
- 위와 같은 EJB의 한계로 인해 마틴 파울러를 비롯한 많은 오피니언 리더들은 EJB와 같은 잘못 설계된 과도한 기술을 피하고, 객체 지향 원리에 따라 만들어진 자바 언어의 기본 기술에 충실하게 비즈니스 로직을 구현하는 POJO 방식으로 돌아서야 한다고 주장했다
- POJO란 Plain Old Java Object 방식의 약자로, 직역하자면 오래된 방식의 간단한 자바 오브젝트이다
- Java EE등의 중량 프레임워크들을 사용하게 되면서, 해당 프레임워크에 종속된 무거운 객체를 만들게 된 것에 반발해 사용하게 된 용어이다
- POJO의 취지는 자바를 자바답게, OOP를 OOP 답게 쓰자는 것이다!
POJO의 정의
- 지정된 클래스를 extends 하면 안된다
- 정의된 인터페이스를 implement 하면 안된다
- 정의된 Annotation을 포함하지 않는다
POJO의 장점
- 코드가 간결해진다
- 자동화 테스트에 유리하다
- 객체지향 설계가 가능하다
- POJO의 단순한 구조는 Over Engineering으로 인한 복잡성을 해결하고, 모듈화시킬 수 있다
- 이러한 POJO의 장점을 살린 다양한 프레임워크들이 등장하였고, 그 중 하나가 바로 Spring 프레임워크이다!
Spring 컨테이너
- 위와 같이 복잡한 EJB의 컨테이너를 대체하기 위해서 등장한 것이 바로 Spring 컨테이너이다
- Spring은 "자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크" 라고 정의된다
- Spring 컨테이너는 특정 클래스를 상속하거나 인터페이스를 구현하지 않는 POJO를 사용하여 많은 복잡성이 제거되었다
- 평범한 자바 클래스를 이용하여 EJB의 기능을 유지하면서 복잡성을 제거해 코드가 가벼워졌고, 스프링에 특화된 인터페이스 구현을 요구하지 않는 등 자바 개발의 폭 넓은 간소화를 실현하였다
- 또한 스프링은 위의 그림과 같이 여러 객체들을 의존성 해결(DI) 및 제어(IoC)하며 객체들의 라이프 사이클을 관리해준다
- Spring은 특정 기술에 종속되지 않고 객체를 관리할 수 있는 컨테이너를 제공하는 것이 스프링의 기본 철학이다
Spring 특징
- 크기와 부하의 측면에서 가볍다
- 제어의 역전(IoC)를 통해 어플리케이션의 느슨한 결합을 도모한다
- 관점 지향 프로그래밍(AOP)을 위한 풍부한 지원을 한다
- 애플리케이션 객체의 생명 주기와 설정을 포함하고 관리한다는 점에서 일종의 컨테이너(container)라고 할 수 있다
- 간단한 컴포넌트로 복잡한 애플리케이션ㅇ르 구성하고 설정할 수 있다
- 확장성이 높다
- DI(의존성 주입)을 지원한다
- POJO(Plain Old Java Object) 방식의 프레임워크이다
DI (Dependency Injection, 의존성 주입)
- 사용자가 직접 new 키워드를 사용하여 객체를 생성하지 않고, 외부(컨테이너)에서 생성된 객체를 주입받는 방식이다
- 의존하는 객체를 직접 생성하는 대신 스프링 컨테이너로부터 의존 객체를 주입(전달)받는 방식이다
- 의존 : A라는 클래스가 어떤 일을 하기 위해 B에 있는 기능을 사용하는 것으로 다른 객체에 의존하여 처리한다는 개념
- 주입 : 생성되어 있는 객체를 주입받는 방식으로 사용하게 되는 것을 말한다
💡 빈 설정 정보를 바탕으로 컨테이너가 자동으로 의존성을 주입한다
즉, 제어하는 주체가 바뀐다 (제어의 역전)
IoC (Inversion of Control, 제어의 역전)
- 객체(인스턴스)의 생성과 소멸 등 개발자가 직접 제어해야 하는 부분들을 프레임워크(컨테이너)가 대신 처리하는 것을 의미한다
- 제어의 주도권이 개발자에서 스프링 프레임워크로 넘어가기 때문에 제어의 역전이라고 한다
Hibernate
- EJB에는 ORM 기술인 Entity Bean 기술을 가지고 있었다
- Spring 컨테이너와 마찬가지로 EJB의 Entity Bean 기술을 위해 Hibernate가 등장하였고, 현재 JPA 표준 인터페이스의 구현체 중 가장 많이 사용되고 있다
https://okky.kr/articles/66000
위 링크를 보면 거의 15년전만 해도 Spring에 대한 믿음이 크지 않아보였다
요즘은 오히려 대규모 프로젝트일수록 Spring을 사용하는 반면, 당시에는 소규모에서만 쓰기 편리한 존재로 인식되는 듯 싶었다
그러나 위처럼 Spring의 편리함을 알고 좋은 것일수록 배우기 어렵지만 배우는 것이 이롭다라는 것을 아는 개발자들 덕분에 Spring이 지금과 같은 위상을 가질 수 있었던 것 같다
이 내용은 그냥 나도 배움을 두려워 하지 않는 개발자가 되고 싶어서 넣어봤다😋
참고)
https://elfinlas.github.io/2017/10/31/javabean/
https://yenny-zzang.tistory.com/67
https://yenny-zzang.tistory.com/68
https://woongsin94.tistory.com/357
728x90
'야미스터디 > Spring' 카테고리의 다른 글
[Spring] Swagger 📌 (0) | 2022.10.06 |
---|---|
[Spring] Dispatcher Servlet 📌 (0) | 2022.09.20 |
[Spring] bean vs component 📌 (0) | 2022.09.08 |
[Spring] maven vs gradle 📌 (0) | 2022.08.18 |
[Spring] Spring Servlet 📌 (0) | 2022.08.13 |
댓글