- EJB 3.0은 아직 Spring에 비해서도 성숙도가 낮다. 여전히 Release는 시간이
필요한 상황이다. JBoss 등이 지원은 하고 있지만, Spring 보단 검증이 덜 되었을 듯
Spring의 최대 강점은 유연성이다. 여타 상용 서비스나 오픈 소스 서비스들을 골라서 쓸 수 있다는 점.
EJB 3.0에 대해서 가장 강점이 이 부분이 아닌가 생각된다.
환경설정 부분에서 두드러진 차이가 있다. 접근 자체가 다르다고 봐야 하나.
Spring은 중앙 집중 관리를 지향하고 있다. 계층화나 Enumeration을 지원하기 때문에
아키텍처 관리에는 EJB 3.0의 방식보다는 강점을 지닌다고 할 수 있다.
※스프링 컨테이너는 객체를 담아두고 있어서 필요할 때 가져다 쓸수 있도록 하고 있다.
◎ 스프링 프레임워크 특징
- 스프링은 경량 컨테이너이다. 스프링은 자바 객체를 담고 있는 컨테이너이다.
스프링은 이들 자바 객체의 생성, 소멸과 같은 라이프 사이클을 관리하며, 스프링으로부터 필요한 객체를 가져와 사용 할 수 있다.
- 스프링은 DI(Dependency Injection) 패턴을 지원한다. 스프링은 설정 파일을 통해서 객체 간의 의존 관계를 설정할 수 있도록 하고 있다.
따라서 객체는 직접 의존하고 있는 객체를 생성하거나 검색할 필요가 없다.
-스프링은 AOP(Aspect Oriented Programming)를 지원한다.
스프링은 자체적으로 AOP를 지원하고 있기 때문에 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통으로 필요로 하지만
실제 모듈의 핵심은 아닌 기능들을 분리해서 각 모듈에 적용할 수 있다.
-스프링은 POJO(Plain Old Java Object)를 지원한다. 스프링 컨테이너에 저장되는 자바 객체는 특정한 인터페이스를 구현하거나 클래스를 상속받지 않아도 된다.
따라서 기존에 작성한 코드를 수정할 필요 없이 스프링에서 사용할 수 있다.
-트랙젝션 처리를 위한 일관된 방법을 제공한다.
JDBC를 사용하든, JTA를 사용하든, 또는 컨테이너가 제공하는 트랙잭션을 사용하든,
설정 파일을 통해 트랜잭션 관련 정보를 입력하기 때문에 트랙잭션 구현에 상관없이 동일한 코드를 여러 환경에서 사용 할 수 있다.
-영속성과 관련된 다양한 API를 지원한다. 스프링은 JDBC를 비롯하여
iBATIS, 하이버네이트,JPA,JDO등 데이터베이스 처리와 관련하여 널리 사용되는 라이브러리와의 연동을 지원하고 있다.
-다양한 API에 대한 연동을 지원한다. 스프링은 JMS, 메일, 스케줄링 등 엔터프라이즈 어플리케이션을 개발하는데 필요한
다양한 API를 설정 파일을 통해서 손쉽게 사용할 수 있도록 하고 있다.
◎ IoC(Inversion of Control)란?
: Spring프레임워크가 가지는 가장 핵심적인 기능은IoC(Inversion of Control)이다.
자바가 등장한 최초에는 객체 생성 및 의존관계에 대한 모든 제어권이 개발자에게 있었다.
그러나, 서블릿,EJB가 등장하면서 제어권이 서블릿과 EJB를 관리하는 서블릿컨테이너 및 EJB컨테이너에게 넘어가게 되었다.
Spring프레임워크도 객체에 대한 생성 및 생명주기를 관리할 수 잇는 기능을 제공하고 있다.
이와 같은 이유때문에 Spring 프레임워크를 Spring 컨테이너,IoC컨테이너와 같은 용어로 부르기도 한다.
* 물론 모든 객체에 대한 제어권을 컨테이너에게 넘겨버린 것은 아니다. 서블릿 컨테이너와 EJB 컨테이너에서도 서블릿과 EJB에 대한 제어권만 컨테이너가 담당하고
나머지 객체에 대한 제어권은 개발자들이 직접 담당하고 있다. 이처럼 Spring 컨테이너도 일부 POJO(Plain Old Java Object)에 대한 제어권을 가진다.
Spring 컨테이너에서 관리되는 POJO는 각 계층의 인터페이스를 담당하는 클래스들에 대한 제어권을 가지는 것이 대부분이다.
◎ Dependency Injection
: DI는 Spring 프레임워크에서 지원하는 IoC의 한형태이다.
DI를 간단히 말하면, 객체 사이의 의존 관계를 객체 자신이 아닌 외부의 조립기(assembler)가 수행한다는 개념이다.
일반적인 웹어플리케이션의 경우 클라이언트의 요청을 받아주는 컨트롤러 객체, 비지니스 로직을 수행하는 서비스 객체, 데이터에 접근을 수행하는 DAO객체 등으로 구성된다.
◎ AOP(Aspect Oriented Programming)
: 로깅,트랙잭션처리,보안과 같은 핵심 로직이 아닌 cross-cutting concern(공통관심사항)을 객체 지향기법(상속이나 패턴등)을 사용해서 여러 모듈에 효과적으로 적용하는데 한계가 있었으며, 이런 하계를 극복하기 위해 AOP라는 기법이 소개되었다.
공통관심사항(cross-cuttion concern)을 별도의 모듈로 구현한 뒤, 각 기능을 필요로 하는 곳에서 사용하게 될 경우, 각 모듈과 공통 모듈 사이의 의존관계는 복잡한 의존 관계를 맺게 된다.
AOP에서는 각 클래스에서 공통 관심 사항을 구현한 모듈에 대한 의존 관계를 갖기보다는, Aspect를 이용하여 핵심 로직을 구현한 각 클래스에 공통 기능을 적용하게 된다.
AOP에서는 핵심 로직을 구현한 클래스를 실행하기 전후에 Aspect를 적용하고, 그 결과로 핵심 로직을 수행하면 그에 앞서 공통 모듈을 실행하거나 또는 로직 수행 이후에 공통 모듈을 수행하는 방식으로 공통 모듈을 적용하게 된다.
AOP에서 중요한 점은 Aspect가 핵심 로직 구현 클래스에 의존하지 않는다는 점이다. AOP에서는 설정 파일이나 설정클래스 등을 이용하여 Aspect를 여러 클래스에 적용할 수 있도록 하고 있다.
◎ Spring Framework 장점
1. 다양한 형태의 Transaction을 선언적으로 사용
2. Remote EJB 사용의 간편성
3. 다양한 Framework과의 통합
4. AOP를 보다 쉽게 적용
5. Covention over configuration 의 결합으로 설정의 최소화
6. Unit Test 지원
7. 설정 관리의 단일화
8. Object Pool을 기본적으로 가지고 있어서 Object 생성 제거의 Overhead 최소화
9. 분산시스템 구성시 비용 최소화
10. Enterprise Application 개발을 위한 Full Stack 지원
◎ Spring Framework 단점
1. 개발자 거부감
- Spring Framework에 대한 막연한 거리감
->IOC, AOP등 새로운 개념에 대해 모두 잘 알아야 할거라는 부담감을 가지고 있음
- 설정 파일 다루기와 Object 재사용에 관한 이해 부족
- Spring Framework의 장점을 살릴 수 있는 도구 제공이 미흡
2. Spring Framework 도입으로 인한 추가 작업
- 설정 파일 관리
->서비스간의 연결을 담당하는 XML관리가 필요 다만, Convention over Configuration의 활용과 generator등을 통해 작업 최소화가 가능
->Spring IDE등의 플러그인을 통해 설정 파일에 대한 통합관리가 가능
- Interface생성
->각 Layer간 연결이 Interface를 통해 이루지기때문에 Interface생성이 필요
*Overhead 작업으로 볼수도 있지만, Layer간 loosed coupling을 위해서는 Spring Framework을 사용하지 않을 경우에도 필요
*tMall의 경우도 Spring framework를 사용하지 않지만, interface기반임
---------------------------------------------------------------------------------------------------------------------------
◎ EJB 개발의 특징과 필요성
- 동시접속자수가 10,000이상 이상인 사이트 구축시 사용하는 컴포넌트 기술
- 동시접속자수가 많은 가운데 안정적인 트랜잭션이 필요한 사이트 구축시 사용
- 접속자수가 많은 공공기관, 기상청, 병무청, 금융, 보험, 포털사이트, 게임사이트, 기업등에서 집중적으로 사용
- EJB 시스템은 속도는 느리지만 개발시에 개발자에게 많은 자동화된 기능을 제공해 분산 시스템 구축을 쉽게 해준다.
- EJB는 JSP, Beans를 사용한 시스템보다 속도는 느리지만 안정적인 분산 시스템을 제공
- 기초기술(JSP, BEANS, RMI, Servlet, Serialization직렬화, Transaction, Connection Pooling)을 알면 EJB는 배우기 쉽고 사용하기 쉬움
- EJB 규약을 집중적으로 습득하면 쉽게 EJB 콤포넌트를 개발 가능
▩ EJB 개발을 위한 프로그래밍 방법 및 장점
(EJB 컨테이너(Weblogic)로 부터 아래의 항목을 자동으로 지원 받을 수 있음으로 어플리케이션을 신속히 구축할 수 있다.)
- 인스턴스 풀링: 객체를 미리 생성하여 메모리에 저장하여 사용준비 상태에 들어가도록 함,
많은 동시접속자에 대한 안정성 지원
- 트랜잭션 처리: 자동으로 컨테이너가 모든 처리메소드에 대하여 트랜잭션을 처리해줌,
안정적인 데이터 조작
- 퍼시스턴스 관리: 빈즈의 상태를 메모리에서 사용여부에 따라 자동으로 활성화/비활성화를 실행해 관리해줌
- FAT Client를 Thin Client로, n-tier 시스템을 구축할 수 있다.
- Weblogic, Webspere주로 사용, 국산은 제우스 사용
- EJB 컴포넌트들이 Loading되어 활동하는 서버 쪽 프로그램, 컴포넌트의 생성, 소멸, 라이프 사이클, 보안,
Threading 등의 서비스를 제공
▩ EJB단점
- 복잡한 프로그래밍 모델
- 특정 환경에 쉽게 종속적인 코드
- 필요없이 특정 기술에 종속적인 코드
- 컨테이너에 안에서만 동작할 수 있는 객체구조
- 자동화된 테스트가 매우 어렵거나 불가능
- 객체지향적이지 않음
- 형편없는 개발생산성
- 한심한 이동성(portablity)
▩ EJB컨테이너가 제공하는 것들
1. 트랜잭션 관리
2. 인증과 접근 제어
3. EJB 인스턴스 풀링
4. 세션관리
5. 지속성 메커니즘
6. 데이터베이스 커넥션 풀링
---------------------------------------------------------------------------------------------------------------------------
※EJB에 비해 Spring을 Java 기술 요건으로 요구하는 건수가 급격하게 증가 추세
※EJB와 Spring은 상호 배타적인 기술이 아니며 두 기술을 동시에 요구하는 경우도 증가세
- EJB 사용하여 개발하게 되면 기술 구조 변경 시, 서버 환경에 종속됨
- 현재 POJO 중심의 개발방식을 기술적으로 지원하며 특정 컴포넌트 모델에 종속적이지 않게 개발하는 것이 추세임
- 구조적인 유연성이 중시되면서 많은 회사들이 Light-weight Platform을 선호함
POJO (Plain Old java Object)란?
POJO (Plain Old java Object) 를 해석하면 평범 자바 오브젝트라고 한다.
POJO를 이해 하기 전 POJO라는 단어가 만들어진 역사적 배경을 살펴볼 필요가 잇다. POJO는 마틴 파울러가 2000년 가을에 열렸던 어느 컨퍼런스의 발표를 준비하면서 처음 만들어낸 말이다. 마틴 파울러는EJB(Enterprise JavaBean)보다는 단순한 자바 오브젝트에 도메인 로직을 넣어 사용하는 것이 여러가지 장점이있는데도 왜 사람들이 그 EJB가 아닌 '평범한자바 오브젝트'를 사용하기를 꺼려 하는지에 대해 의문을 가졌다. 그리고 그는 단순한 오브젝트에는 EJB와 같은 그럴듯한 이름이 없어어서 그 사용을 주저하는 것이라고 결론 내렸다.
그래서 만든 단어가 POJO라는 용어인 것이다. POJO기반의 기술을 사용한다고 말하면 왠지 첨단 기술을 사용하는 앞선 개발자인 듯한 인상을 주기 때문인다.
POJO기반의 프로그래밍 기술이 EJB의 강력한 대안으로 등장했고 ,POJO 기반 프레임워크 ,POJO 애플리케이션을 위한 플랫폼 등이점점 인기를 끌게 되었고, 결국 POJO가 배제하려고 했던 EJB는 POJO기반의 기술에 밀려 이제 레거시 기술로 사라질 위기에처했다. 그렇다면 단지 EJB를 사용하지 않으면 모두 POJO라고 할 수 있을까? 그렇지 않다. POJO프로그래밍이라는 개념은단지 "EJB가 아닌 자바"이상의 특징을 가지고 있는 프로그래밍 모델이다. POJO기반의 개발은 생각보다 단순하지 않다.
POJO를 좀더 이해하려면 EJB의 장단점을 함께 이해해야 한다. 그것은 POJO 프로그래밍이 다시 EJB시대이전으로 돌아 가자는 것이 아니고 ,EJB를 넘어 그보다 더 앞으로 나아가자는 것이기 때문이다.
EJB를 사용하지 말고 POJO를 쓰자는 것은 EJB이전의 방식으로 돌아 가는 것을 의미한다면 또 다른 문제가 발생 할 수 밖에없다. 여전히 복잡한 로우레벨의 API를 이용해 코드를 작성해야 하고, 많은 기술적인 문제를 애플리케이션 코드에 그대로 노출시켜개발해야 한다면 기껏 POJO로의 복귀 덕분에 얻는 많은 장점들을 놓칠 수 밖에 없다.
그래서 등장한 것이 POJO 기반의 프레임워크이다. POJO프레임워크는 POJO를 이용한 애플리케이션 개발이 가진 특징과 장점을 그대로 살리면서 EJB에서 제공하는 엔터프라이즈 서비스와 기술을 그대로 사용할 수 있도록 도와주느 프레임워크이다. 나아가 이는 기존의 EJB에서보다 훨씬 더 세련되고 나은 방법이다. 데표적인 프레임웤 스프링 하이버네이트~!
참고로 스프링은 엔터프라이즈 서비스들을 POJO기반으로 만든 비지니스 오브젝트에서 사용할 수 있게 한다. 대표적인 선언적인트랜잭션 서비스와 보안이다. 또한 EJB와 마찬가지로 오브젝트 컨테이너를 제공해서 인스턴스의 라이프사이클을 과리하고 필요에 따르스레딩, 풀링 및 서비스 인젝션 등의 기능을 제공한다. 또한 OOP를 더 OOP답게 사용 할 수있게 하는 AOP기술을 적용해서POJO개발을 더 쉽게 만든다.
POJO프로그램의 진정한 가치는 자바의 객체지향적인 특징을 살려 비지니스 로직에 충실한 개발이 가능 하도록 하는것이기도 하다.
[출처] EJB&SPRING|작성자 Baek
http://blog.naver.com/ikhyun84/20086106665
EJB&SPRING
- EJB 3.0은 아직 Spring에 비해서도 성숙도가 낮다. 여전히 Release는 시간이 필요한 상황이다. JB...
blog.naver.com
'프로그래밍 > Spring-boot' 카테고리의 다른 글
| [Spring] DI, IoC 정리 (0) | 2021.10.14 |
|---|---|
| [Spring] 의존성 주입(Dependency Injection, DI)이란? 및 Spring이 의존성 주입을 지원하는 이유 (0) | 2021.10.14 |
| [Spring] 스프링 의존성 주입(DI) 이란? (0) | 2021.10.14 |
| Spring의 특징과 Spring Boot와의 차이점 (0) | 2021.10.11 |
| Spring (1) 역사, 핵심 요소 (0) | 2021.10.11 |