스프링 프레임웍의 탄생배경

- 스프링 프레임웍의 탄생 배경

 

처음 java 가 나왔을 때, applet 은 동적인 웹어플리케이션의 구현을 가능하게 했지만, 너무 단순하여 실제 실무에는 적용하기 어려웠음.

그래서 화면단에 쓰는 분품 정도로 남아 있었음.

 

 

96년 12월 sun 에서 javaBeans 1.0 스펙을 발표함.

: 

복잡한 실무에 적용 가능하도록 

재사용 가능하고

더 복잡한 어플리케이션에 이식도 가능한 오브젝트가 스펙에 정의됨.

 

보통 '재사용 가능한 컴포넌트'로 이해하고 있는 빈즈가 이 때 나온 개념임.

이 스펙은 코딩 정책의 묶음(a set of coding policies)이었고

의도했던 바는 java beans 를 재사용 가능한 컴포넌트로 사용하도록 하는 것이었음.

그러나 이것도 실무에 사용하기엔 너무 단순했음.

결과적으로 UI마법사 정도에만 이용되었음.

 

 

또, 이  javaBeans 1.0 스펙은 트랜젝션, 보안, 분산 컴퓨팅 환경을 지원하지 않았음(스펙에 정의되지 않았다는 말)

 

 

이후, 98년에 sun 에서 트랜젝션, 보안, 분산 컴퓨팅 환경을 지원하는 EJB (Eeterprise Java Beans) 스펙을 발표함 

 

- 어느 프로젝이든 들어가기전에 협력업체 사장님들께서 인터뷰 할 때마다 물어보시던 

'ejb' 할 줄 알아요? 라는 질문에 나오는 그 ejb 가 java Beans 스펙을 고도화시켰달까요? 뭐 그런겁니다. IDE 도움 없이 ejb 를 스펙대로 구현할 수 있는 사람은 거의 없죠. 

물론 스펙을 보면서 구현하면 안될건 없겠지만,구현할 필요도 없는게 홈인터페이스, 리모트 인터페이스 등등을 IDE 에서 generating 해 주거든요.

스펙대로 구현한다면 그건 WAS 를 만드는 사람들이죠. 

 

 

 EJB (Eeterprise Java Beans)의 주된 목적은 WAS 단에서 트랜젝션 지원, 보안 강화 두 가지임(분산 환경 지원은 기존 rmi를 확장한 개념). 코드 레벨에서 개발자가 트랜젝션 관련 코드를 넣지 않아도 WAS 단에서 지원해 주는 것. 그러니 금융권에선 좀 무거워도 돈이 걸린 업무에서 트랜잭션 처리가 되지않아서 roll back 이 안 되는 등의 참사를 예방하기 위해 지금도 ejb 쓰고 있을 것임

 

근데 이 ejb 는 사용하기에 너무 복잡했었음(지금은 인텔리제이나 이클립스 같은 IDE 에서 아주 간단하게 해 주지만, 당시는 jbuilder 도 generating 해주는 기능이 없었다고 알고 있음)

 

- 스프링 프레임웍의 탄생

이 때, 오픈 소스 프로젝으로 스프링이 나왔음.

스프링은 ejb 를 쓰지 않고도 엔터프라이즈급 어플리케이션 개발이 가능하도록 하기 위해 나온 것임.

(ejb3 스펙은 사용하기에 많이 쉬워졌지만 이미 그 이전에 스프링이 나오면서 널리 확산되어 쓰이기 시작함)

결국 당시에 복잡했던 ejb 를 사용하지 않아도 되고,

그냥 j2se 를 사용하면서 트랜젝션과 보안도 지원 받을 수 있고, java Beans 스펙에 정의된 재사용성도 보증해 주는 프레임웍으로 탄생한 것.

 

 

위 책 29쪽에 보면 아래와 같이 나옴.

1.5 Summary

...

Spring aims to

make enterprise Java development easier and to promote loosely coupled code

...

 

 

참고) loosely coupled code 란 각 클래스간의 의존성을 약화시킨 코드를 말함. 

: 

보통은 실무에서는 수백 수천개의 클래스들을 생성하게 되고, 

이 여러개의 클래스들이 서로 다른 클래스들의 객체를 생성하면서 의존성(Dependency) 을 갖게 됨.

이게 Coupling 인데 이게 너무 타이트하게 되어 버리면 테스트할 때 코드도 많아지고

재사용하기도 어려워 짐.

또, 필요없이 계속 메모리에 각 클래스 객체들을 생성하게 함.

그런데 스프링에서는 DI(Dependency Injection)이라는 나름의 개념으로 각 클래스들 간의 의존성을 최소화 시키고 객체 생성도 매번 생성되는게 아니라 java Beans 스펙에서 의도했던 대로 (한 번 생성하면 가비지 컬렉터에 의해 지워졌다가 다시 생성되는게 아니라) 한 번만 생성하여 재사용되도록 메모리상의 객체 관리를 해 준다는 것.

 

물론 어느정도의 커플링은 당연히 필요함. 하나의 클래스 안에 모든 비지니스 로직을 넣지 않는 한, 의존성이 전혀 없는 코드는 있을수 없음. 

 

레퍼런스 : http://blog.naver.com/acatholic/90176578100