멀리 돌아왔다. 드디어 이 시리즈의 가장 큰 목표, Spring이다. Spring이 등장한 배경을 알기 위해 이 시리즈를 기획했는데, 깊이 들어가다보니 EJB가 나왔고, EJB라는 것 자체가 그렇게 어려우면 안쓰면 될 텐데! 하고 더 파보다 보니 java의 등장과 발전 과정이 나왔기에, 시리즈를 기획할 수 밖에 없었다. 아무튼, 이번 포스팅의 주제는 Spring의 등장이다. 자료 조사 자체가 만만치 않았다. 여러 서적과 블로그, 당시 진행했던 강연과 같은 것들을 훑어 보고 이를 정리하다보니 많은 시간이 걸려 이 포스팅이 늦어지게 되었다. 먼저, 지난 포스팅 마무리 단계에서 나왔던 EJB를 사용하게 된 계기에 대해 말해보자면, 트랜잭션 관리 인증과 접근 제어 EJB 인스턴스 풀링 세션 관리 DB와의 커넥션 관리 위와 같은 로우 레벨 기술을 개발자들이 신경쓰지 않아도 될 수 있게, EJB 사양이 이를 대신 해주었던 것이다. 하지만 이를 위해 E

이전 포스팅에서는 ejb의 탄생 배경과 특징, 가능한 기능에 대해 다루어 보았다. 이번 포스팅은 어떤 구조를 가지며, 동작 원리는 어떻게 되는 지 정리하려 한다. > #### 용어 정리 Enterprise Beans, EJB Bean - 빈 EJB Container - 컨테이너 먼저 EJB를 사용하기 위해서는, 두 가지가 필요하다. 예전 web server와 WAS를 다룬 포스팅에서 잠깐 언급했는데, WAS의 내부 모듈이면서도 WAS의 다른 이름인 Web Container, 그리고 EJB Container이다.(일부 문서에서는 EJB 엔진이라고 표현하기도 한다.) 그리고 빈은 컨테이너 내부에서 동작하며, 컨테이너는 빈들의 lifecycle 관리를 맡는다. *빈

Servlet, JSP의 등장 이후 시스템 규모가 점점 커져갔다. 대량의 트래픽을 감당하기 위해 서버를 나누고, 여러 대의 서버와 DB가 데이터를 주고 받다보니 시스템 구조의 복잡성이 증가했다. 한 가지 요청을 위해 여러 서버나 DB가 개입해야 한다든지, 여러 db 요청이 오가야 한다든지, 요청 중 다른 요청을 동시에 처리해야 한다든지 등의 복잡한 기술이 요구되기 시작했다. 여러 시스템이 운용되다보니, 데이터가 오가는 데에 있어 보안이 취약해지는 부분이 생기기도 했다. 하지만 기업 내 한정된 개발자 풀 내에서 비즈니스 로직 뿐만 아니라 위의 문제와 요구를 해결하기는 쉽지 않았다. 이러한 문제를 해결하고자 나온 기술이 바로 이번 포스팅에 소개할 EJB이다. EJB EJB의 사상은 위에 제기된 여러 문제, 즉 로우 레벨의 기술에 대한 문제를 신경쓸 필요 없이 비즈니스 로직에만 집중할 수 있게 하는 데에 있다. EJB는 독립적으로 개발한 컴포넌트를 배포하고, 서로 연동해