2013년 9월 1일 일요일

EJB개요 - 분산 컴퓨팅 기술(Distributed Computing Technology)

분산 컴퓨팅 기술(Distributed Computing Technology)


EJB를 시작하기전 분산프로그래밍에 대해 이해를 한다면 EJB를 왜 배워야 하며 어떻게 활용할 수 있는지 쉽게 이해 할 수 있는데 먼저 2-Tier, 3-Tier, N-Tier에 대해 알아보도록 하겠습니다.

구로디지털단지역 오엔제이프로그래밍 실무교육센터  
(Java , Oracle, SQL, Oracle Tuning,BackUP&Recovery, ASP.NET, C#, 채용확정무상교육) 
www.onjprograamming.co.kr

1.     2-Tier
-       Visual Basic이나 Power Builder라는 프로그래밍 언어로 개발된 프로그램이 데이터베이스에 직접 접근하여 비즈니스로직을 처리하는 경우를 일컫음.
-       장단점 : 클라이언트에서 모든 비즈니스로직을 처리하므로 클라이언트의 성능이 좋아야 하며 비즈니스로직이 변경될 경우 모든 클라이언트 프로그램을 재배포해야 하며 비용이 발생한다. 그러므로 강력한 서버보다는 강력한 클라이언트의 자원을 이용하는 환경이라고 할 수 있습니다.

 
 
2.     3-Tier
-       2-Tier인 클라이언트/서버 환경의 단점을 극복하기 위해 등장했는데 기존의 클라이언트/서버 사이에 중간단계(미들웨어)를 더 둔 것인데 첫번째 계층은 사용자의 입력을 받고 보여지는 것을 담당하는 프리젠ㅌ테이션 계층이며 두번째 계층은 프리젠테이션 계층에서 입력한 값을 받아들여 실제로 비즈니스로직을 처리하는 애플리케이션 계층을 이야기하며 세번째 계층은 데이터를 저장하는 데이터베이스 서버를 이야기 합니다. 대표적인 것이 일반적인 웹 환경 입니다.
-       이러한 3-Tier환경은 2-Tier와 다르게 비즈니스로직이 변경되더라도 클라이언트를 모두 수정할 필요가 없으며 웹서버에서 해당 비즈니스로직을 처리하는 부분만 수종하면 되며 클라이언트 역시 브라우저를 실행 할 정도가 되면 되므로 가벼운 구조를 가질 수 있습니다.
 
 
3.     N-Tier
-       3-Tier 환경에서 코드 재사용의 어려움을 극복하기 위해 나타난 것이 N-Tier 환경인데 이는 3-Tier의 비즈니스로직을 담당하는 애플리케이션 계층을 좀 더 쉽게 구현한 구조를 가지는데, 비즈니스로직을 담당하는 애플리케이션 계층을 내부에서 로직에 따라 여러 부분(콤포넌트)으로 나눈 후 서로 통신하는 방법으로 처리하도록 구현한다는 의미 입니다. 이러한 구조의 장점은 비즈니스로직이 변경될 경우 해당 콤포넌트만 수정하면 된다는 장점이 있습니다.
 
 
4.     N-Tier 환경과 EJB
-       결국 EJB N-Tier 환경을 쉽게 구축하기 위해 탄생되었으며 EJB는 콤포넌트 기반으로 작성되므로 내부적인 통신은 RMI를 사용합니다.
-       EJB 아키텍쳐는 개발자가 분산시스템을 쉽게 구성하도록 되어 있는데 만약 EJB를 사용하지 않은 경우 개발자는 분산객체시스템을 구성하려면 트랜잭션, 보안, 캐싱 등 많은 부분을 고민해야 하며 EJB 아키텍처는 이러한 개발자의 어려움을 해소하기 위해 대부분의 내용이 이미 구현되어 있으며 개발자는 EJB 명세에 맞추어 비즈니스로직을 담당하는 콤포넌트만 작성하면 됩니다.
 
5.     EJB를 사용할 때의 장점 과 단점
장점
·       정형화된 비즈니스 계층을 제공한다. EJB는 비즈니스 계층에 대하여 논리적인 분리뿐만 아니라 물리적인 분리까지 가능하도록 지원하고 있다.  
·      선언적인 트랜잭션 관리와 같이 Non EJB 아키텍처에는 지원하기 힘들었던 기능을 EJB 컨테이너가 제공한다.  
·      EJB는 다양한 클라이언트에 대한 지원이 가능하다. EJB는 웹 UI 계층뿐만 아니라 Swing과 같은 GUI 클라이언트도 지원하는 것이 가능하다.  
·         분산 기능을 지원하는 것이 가능하다.(분산시스템에서 구현하기 어려운 부분은 이미 작성되어 있기 때문에 개발자는 비즈니스로비지 위한 콤포넌트만 만들면 됨.)
·      최근에는 드문 경우지만 비즈니스 객체를 여러 서버에 분산시키는 것이 가능하다.  
·      콤포넌트 중심으로 개발되었으므로 업무에 대한 인수인계가 쉽다. 모든 소스코드를 이해하는 것이 아니라 해당 컴포넌트의 비즈니스 메소드에 대한 기능만 익히면 된다.
·       
 
단점 
·          가장 큰 문제점은 실행 속도의 문제다. 분산 환경을 지원하기 위하여 객체를 직렬화하는 과정 때문에 실행 속도의 저하가 발생한다.
·          개발 사이클의 소스 수정, 빌드, 배포, 테스트와 같이 복합한 과정을 거치기 때문에 초기 개발 생산성이 저하되는 결과를 가져온다.  
·         EJB EJB 컨테이너가 종속적이기 때문에 개발한 후 EJB 컨테이너에 배포한 다음에 테스트를 진행해야 한다이는 테스트를 어렵게 만들며, 테스트의 어려움으로 인해 제품의 질(Quality)이 저하되는 결과를 초래한다.  
·         EJB의 실행 속도 문제를 해결하기 위한 방법으로 EJB를 위한 변형된 패턴들이 나타나면서 객체 지향 적으로 개발하는데 제약사항이 된다.  
·         EJB 자체 스팩이 가지고 있는 실행 속도가 떨어진다는 문제로 인해 EJB 컨테이너를 만드는 대형 벤더들 나름대로 자신들만의 기능들을 추가함으로써 EJB 컨테이너 사이의 이식성(Portability)이 떨어진다.  
 
 
6.     Non EJB인 경우 장점과 단점
장점
-       추가적인 교육 없이도 초보 개발자들이 쉽게 이해하고 개발하는 것이 가능하다. 특히 국내와 같이 IT가 급성장하면서 프로그램에 대한 깊이 있는 지식 없이 웹 애플리케이션을 개발하는 개발자들이 많은 환경에서는 쉽게 접근할 수 있는 개발 방식이다.  
-       초기 개발속도가 빠르므로 단기적으로 가시적인 성과를 낼 수 있다
-       굳이 값비싼 EJB 컨테이너가 아니 서블릿 컨테이너만으로 운영하는 것이 가능하다.  
-       EJB 컨테이너 보다 서블릿 컨테이너의 이식성(Portability)이 훨씬 좋다. 따라서 이 개발 방식을 이용할 경우 추후에 컨테이너가 바뀌더라도 손쉽게 대응할 수 있다
-       개발주기가 EJB 보다 짧기 때문에 개발 생산성의 향상을 가져올 수 있다. EJB와 같은 경우에는 애플리케이션이 변경될 경우 개발, 빌드, 배포, 테스트 과정을 거쳐야 하지만 이 개발 방식은 개발테스트 과정을 통하여 개발하는 것이 가능하다.  
 
단점 
-       초기 개발 속도가 빠르지만 프로젝트가 진행되면서 추가 요청사항이나 변경사항이 발생할 경우 대응 속도가 느려 프로젝트 후반으로 갈수록 개발 속도가 느려지게 된다. 물론 이 절에서 살펴본 바와 같이 명확한 계층 분리와 견고한 설계가 바탕이 된다면 이같은 문제점은 극복할 수 있다.  
-       명확한 계층 분리를 하기 어렵다. 계층 분리가 명확하지 않기 때문에 중복되는 코드가 많이 발생할 확률이 높다. 이로 인해 유지보수 비용이 높다.  
-       사내에 일관된 개발 방식을 가지기 어렵다. 이 아키텍처를 이용할 경우 한 회사내에서 진행하는 프로젝트마다 서로 다른 아키텍처로 개발을 진행하는 경우가 많기 때문에 유지보수 비용의 증가를 가져온다.  
-       분산 환경을 지원할 수 없다. 외부 시스템과 인터페이스하기 위하여 분산 환경 지원이 필요할 경우 지원하기 힘들다. 만약 비즈니스 계층을 명확하게 분리하여 개발되어 있지 않다면 외부 시스템과의 인터페이스를 지원하기 위하여 애플리케이션 전체를 재개발해야 되는 경우도 발생한다. 특히 최근 웹서비스 같은 기술이 등장하고외부 시스템과의 필요성이 점점 더 증가하는 시점에 비즈니스 계층이 독립적으로 분리되어 있지 않다면 분산환경을 지원하기 더더욱 힘들다.  
-       비즈니스 로직을 구현하고 있는 비즈니스 객체의 생명주기를 프로그램에 직접 관리해야 한다. 서블릿과 EJB의 경우 빈의 생명주기를 컨테이너에서 관리하는 것이 가능하다. 그러나 POJO에 대한 생명주기는 프로글매에 개발자들이 직접 관리할 수밖에 없다.  
-       EJB가 지원하고 있는 선언적인 트랜잭션(Transaction)과 같은 기능을 사용할 수 없다. 애플리케이션을 개발하면서 상당히 많은 시간을 투자해야 하는 부분이 트랜잭션 처리이다. 그러나 Non EJB 아키텍처에서는 프로그램에서 직접 작성하여 트랜잭션을 처리할 수밖에 없다.   

댓글 없음:

댓글 쓰기