짧게 쓴 엔터프라이즈 애플리케이션 개발환경의 역사

Tags:

커멘트 주시면 수정들어갑니다~ ^^;

  • 짧게 쓴 엔터프라이즈 애플리케이션 개발환경의 역사
    1. 과거에는 DB에서 트랜잭션과 보안을 모두 관리했다.
    2. 그런데 예전에는 사용자마다 별개의 계정을 사용하려면 scalability가 떨어진다. 처리 속도면에서 DB connection을 재사용하는 것이 가장 좋으므로, 그렇게 하기로 한다.
    3. connection을 재사용하려면, 결과적으로 컨넥션을 소유한 객체를 재사용해야한다. 즉, object pooling의 개념이 나타난다.
    4. 결국 객체를 재사용하고, 컨넥션을 재사용하다보니 하나의 database connection만 사용하게 되었다.
    5. 하나의 connection만 사용하게 되니 transaction과 보안의 중심이 객체로 옮겨지게 되었다.
    6. 객체에서 transaction과 보안을 처리하려니 이게 보통일이 아니게되었다. 그래서 trasaction과 보안을 처리하기 위한 다양한 API를 만들었다. 그러나 그 API를 적절하게 사용하는 것도 보통일이 아니었다.
    7. 여기서 발상의 전환이 일어나는데, API를 만드는게 아니라 객체를 컨테이너안에 넣고, 컨테이너가 객체의 생명주기(lifecycle)를 관리하고, 객체의 모든 메소드에 대한 보안과 트랜잭션을 처리하는게 어떨까하고 생각하게되었다.
    8. MS의 COM+ 가 완성되었다.
    9. SUN의 EJB가 COM+를 배꼈다. 대신 엔티티 빈(entity beans)과, 상태 유지 세션빈(stateful session beans)를 추가하였다.
    10. MS가 JAVA를 배끼고, 이제 .NET을 만든다. .NET에서는 attribute라는 개념을 사용해 EJB보다 훨씬 간단하게 객체를 풀링하고, 객체의 트랜잭션을 관리하고, 객체의 보안을 관리할 수 있게 되었다.
    11. 다시 JAVA가 .NET의 attribute를 배껴서 annotation이라는 것을 만들어내고, 이를 사용한 쉬운 엔터프라이즈 애플리케이션 개발 환경을 만들고자 하게 되었다. 이것이 2005년말~2006년초사이에 나타날 J2EE 5 이다.
  • 참고문서
    • Com+ and Battle for the Middle Tier by Roger Sessions
    • Understanding COM+ by David S. Platt
  • 수정의 여지
    • 컴포넌트에 대한 기술없이 곧바로 분산 컴포넌트로 점프해서 아쉽다. 하지만 저자의 지식 부족으로 ‘컴포넌트’라는 개념이 나타난 시기와 이유를 명료하게 위의 아이템들 사이에 끼워넣지 못하였다.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *