스프링&웹 | 기초 지식 1 - 스프링 등장 배경 & 웹 간단 구조

참고) 스프링

∨ 특별히 웹 애플리케이션에 특화된 프레임워크는 XXXX

∨ 규모가 큰 애플리케이션을 자바로 만들 때 필요한 프레임워크 O

∨ 하지만 학습은 웹 애플리케이션 기준으로 진행

 

 

---

 

스프링 등장 이해하기

 

∨ 초반 웹 기술 : HTML(정적콘텐츠)를 표시하는 기술

∨ CGI 기술 등장 : 동적콘텐츠 반환이 가능해짐

- 참고: CGI란 HTTP의 요청으로 실행되는 프로그램을 말한다(Common Gateway Interface)

웹브라우저의 요청을 받으면 CGI가 해당 프로그램을 실행해서 처리결과를 동적으로 반환한다.

CGI의 문제점 : 처리 요청시마다 프로그램이 실행됨 & 세션 관리가 없음 

=> 처리 요청 증가시 : 성능저하와 트랜잭션 관리 어려움

 

∨ JSP와 Servlet 기술 등장 :

실행기반 : 웹 컨테이너 - 세션을 관리 가능해짐 & HTTP 통신 은닉

구조의 장점 : 페이지생성 로직 and 비즈니스 로직을 분리 가능해짐

                     (JSP로 페이지 생성 & Servlet으로 비즈니스 로직 처리)

참고 : JSP, Servlet은 멀티 스레드로 실행된다. 

 

∨ Enterprise Java Beans(EJB) 등장

참고) EJB 3 이후버전 얘기X - 과거의 EJB 얘기임

EJB 컨테이너에 의해서

- 분산된 컴포넌트(EJB 컴포넌트)를 같은 머신에 있는 것처럼 접근가능하게 한다. 

- 분산된 DB의 트랜잭션을 마치 하나의 DB만 있는 것처럼 제어할 수 있게 한다.

- 그래서  EJB가 권장 웹 설계방식의 일부분이 되기도 했다.

- EJB는 '기술이 필요없는 DB 액세스 프레임워크', '재사용 가능한 컴포넌트'라는 좋은 인식이 있었다.

하지만 EJB 컴포넌트는 분산환경용 컴포넌트일 뿐이다.

- 그래서 '원격 액세스'만 지원을 했는데, 사실 웹 애플리케이션에서는 '로컬 액세스'가 필요하다

- 사실상 웹 애플리케이션에 분산처리를 사용할 일이 거의 없었다.

- EJB 컴포넌트는 EJB 컨테이너에 의존하기 때문에 테스트도 어려웠고, EJB 사양도 복잡했다고 한다.

 

∨ J2EE가 버전업 될수록 무거워졌다

( 즉 JSP, Servlet, EJB 기능이 +++ )

* J2EE : 그냥 자바의 엔터프라이즈 에디션임 java EE 이런거

너무 무거운 J2EE의 EJB 컨테이너 대신,

 

∨ "스프링"이라는 컨테이너 고안 : DI와 AOP 기능을 가진 "DIxAOP 컨테이너" 

POJO의 생명주기관리 & 오브젝트간 의존관계 해결하는 아키텍처를 구현한 컨테이너

* POJO(Plain Old Java Object) : 컨테이너와 프레임워크 등에 의존하지 않는 일반 자바 오브젝트

다시 말해 이 컨테이너에 실을 수 있는 오브젝트는 POJO(일반 자바 오브젝트)이다.

EJB 컴포넌트는 EJB 컨테이너에 의존하므로 단위테스트를 수행하기 어렵지만,

일반 자바 오브젝트 POJO는 DIxAOP 컨테이너로 관리되어 어떠한 컨테이너에도 의존하지 않아 쉬운 단위테스트 가능

+ 선언적 트랜잭션 관리(EJB의 장점)를 POJO로 구현

+ ORM(다양한 O/R 매핑 프레임워크)를 통해 DB접근

 

∨ 이렇게 현재는 스프링이 Java(EE)의 표준 프레임워크로 자리잡았다

 

 

---

 

 

참고) 스프링 동작 규정 파일

∨ Bean 정의 파일 : 스프링의 동작을 규정하는 파일

=> 비대화, 관리 어려움 ↑

∨ 어노테이션의 등장 - Bean 정의 파일을 간결하게 작성 가능해짐

∨ JavaConfig라는 Java 클래스에서 Bean 정의도 가능

=> Bean 정의 파일 (XML로 기술함)은 요즘 잘 안쓰고 JavaConfig와 어노테이션을 같이 사용한다.

 

 

참고) 스프링의 서브 프로젝트

∨ 스프링은 하나의 거대한 프로젝트이며, 스프링의 다양한 서브프로젝트와 라이브러리를 적극 활용한다.

∨ 취급해볼 스프링 프로젝트는 다음과 같다

스프링 프레임워크(DI x AOP, 스프링 MVC, 스프링 JDBC), 스프링 캐시

스프링 시큐리티, 스프링 데이터, 스프링 배치, 스프링 부트

 

 

---

 

웹 애플리케이션 이해하기

 

∨ 초기 : WWW와 HTML의 유행

∨ 일반적인 웹 시스템(WWW)의 구조

클라이언트(웹 브라우저)가 서버에 콘텐츠를 요청한다.

if 정적콘텐츠 요청 :

웹 서버가 해당 HTML(정적콘텐츠)을 읽어와 표시해준다.

if 동적콘텐츠 요청 :

웹 서버가 애플리케이션 서버에 처리 요청 => 처리 결과를 웹 서버에서 받아 웹브라우저에 표시

- 처리? : 대부분은 RDB에서 데이터를 읽어오거나 가공

- RDB : Relational Database, 관계형 데이터베이스, key-value 관계를 테이블화

 

.

.

 

Let define 웹 애플리케이션 this way... 

∨ 여러 사용자가 인터넷을 통해 DB에 접근하고 정보를 읽고 쓸 수 있게 만들어진

웹 브라우저와 RDB를 이용한 애플리케이션

 

Then 웹 애플리케이션의 구조

∨ 웹 서버는 다음 동작을 반복한다

→ 웹브라우저 버튼 클릭

→ 해당 비즈니스 로직을 따라 처리 (RDB 데이터를 이용)

→ 처리 결과 전송

→ 웹브라우저에 표시

 

※ 처리 결과 전송 후 세션(접속)이 끊기면 상태를 저장할 수 없다(stateless)

이 문제점은 추후에 자세히.. 

 

---

 

- 끝 -

 

 

스프링 등장 배경이랑

웹 애플리케이션의 간단한 구조만 짚어봤다.

 

다음 :

웹 애플리케이션 아키텍처 ★★★