'EJB'에 해당되는 글 2건

  1. 2006.08.06 EJB는 언제 사용해야 하는가?
  2. 2006.08.06 EJB 는 왜 필요할까요?
engineering/System Eng.2006. 8. 6. 23:31

EJB는 언제 사용해야 하는가?

EJB는 언제 사용해야 하는가?

2004-03-25
조병욱


EJB 는 J2EE의 기술의 하나로, 분명히 편리하고 강력한 첨단 기술임에는 틀림이 없다. 그렇지만, EJB의 특징과 장단점을 제대로 인식하고 EJB 사용하는 개발자는 많지 않다고 느껴진다.
특히나 대부분의 EJB로 이루어지는 부분에 대해서는 EJB가 아니라 일반 Java Beans로도 구현이 가능하다. 그렇다면 언제 EJB를 사용해야 되는것인지에 대해서 알아보도록 하자.

일반 Servlet/JSP는 Presentation 즉 데이타를 화면에 나타내기위한 부분을 위해서 디자인 된 부분이다. 종종 웹개발자들이 개발을 하면서 Business Logic이나 SQL문장까지 Servlet/JSP에 들어가는 일이 있는데, 이렇게 되면 Presentaion과 Logic의 분리가 불가능하다. 즉 둘중 하나만 바뀌더라도 코드를 수정해야된다.

EJB를 사용하지 않더라도
Servlet/JSP (Presentation) -> Java Beans (Business Logic) -> DBMS
이런 방식으로 구현하는게 좀더 모범답안이다.
대부분의 Web Application은 이런 방식으로 개발이 가능하다.
그 외에도 간단한 WebService의 개발이나, 또는 3 Tier가 아닌 위에서 제시한 2 Tier 모델인 경우에도 굳이 EJB를 사용할 필요가 없다.

EJB 선택에 있어서 잘못된 상식
그렇다면 EJB는 언제 사용하는가?
개발자들과 EJB에 대해서 이야기 해보면 몇가지 잘못된 상식이 있다. 하나하나 집어 보도록 하자.

EJB server는 비싸다?
EJB 도입에 있어서 망설이는 부분중 하나가 WAS의 가격문제이다. WAS 자체의 가격만으로만 보면 절대 싼 가격은 아니다. 그러나 프로젝트 전체를 봤을때는 반대로 비싼 가격이 아니다. 프로젝트 전체란 단순히 개발 비용만을 말하는것이 아니라 유지 보수 비용을 포함한다. 더군다나, J2EE Framework (EJB, Load Balancing,Failover,Transaction 처리 등)을 직접 구현하지 않고 이미 표준화되고 안정화된 환경을 사용하는것에 대하면 오히려 개발비용을 효과적으로 줄일 수 있는 방안이기도 하다.

단, 국내 개발자들이 WAS선택에 있어서 고려해야할점은 합리적인 선택이 필요하다는 것이다. 같은 WAS라도 지원하는 Feature에 따라서 가격이 틀리기 때문에 구현하고 사용하고자 하는 Feature를 갖추고 있는 WAS Version을 구입할 필요가 있다.

그리고 구입전에는 용량 산정작업 (Capacity Planing)이 필요하다. 주먹구구식으로 HW성능과 WAS의 개수를 선택하다보면 쓸데없이 비용만 낭비하기 마련이다. 용량 산정에 대한 사전 작업과 컨설팅에 비용을 투자한다면 그로 인해서 쓸데 없이 사양만 높은 HW와 많은 수의 WAS를 사는 일을 줄여서 프로젝트 비용을 많이 조정할 수 있을 것이다. ( 실제로도 4CPU만으로도 충분한 프로젝트를 12CPU이상으로 진행하는 경우도 많이 봤다. 국내에서는 컨설팅 문화가 정착되지 않은 이유도 있겠지만, 효과적인 컨설팅은 프로젝트의 위험요소 제거와 정확한 진행에 많은 도움을 준다. 물론 컨설팅 회사가 그만한 노하우를 가져야 함은 두말할나위 없는 사항이다.)

그외에 방안으로는 공개 WAS를 사용하는 방법도 있다. 대신 중요한 업무를 다루는 프로젝트의 경우 공개 WAS는 기술지원의 한계와 가이드의 부제등 때문에 절대 추천하고 싶지 않다.

EJB로 나누면 Component 모델이나 각 Tier를 구분하기가 훨씬 편리하다?

물론 EJB를 사용하면 Business Logic이나 Data Model을 분리하기도 좋고, Component 화 하기도 좋다. 그러나 이런 이유만으로 EJB를 선택하는것은 합당하지 못하다. EJB를 사용하지 않더라도 Java Beans 만으로도 충분히 Component Model이나 Tier 구분이 가능하다.

그럼 EJB 는 언제 사용해야 하는가?

EJB를 언제 사용하느냐는 것은 EJB의 장점과도 연관이 된다.

좀더 빠르고 안정적인 시스템을 위하여…
EJB는 instance pooling,transaction 처리, 보안,CMP,CMR 그리고 데이타 캐슁과 클러스터링을 통한 Load Balancing과 Fail over 기능들을 이미 다 구현해놓은 frame-work이다. 간단하게 Session Bean을 통해서 SQL문을 하나 처리한다 하더라도 그 안에는 이런 기능이 이미 구현되어 있고, 이런 기능들은 이미 vendor들에 의해서 최적화 되고 안정성이 검증된 기술들이다.

이런 기능들을 일일이 구현하기 위해서는 framework등을 만들어야 하는데, 여기에 소요되는 시간과 기술 그리고 시행 착오에 드는 비용이 매우 크다. 프로젝트 하나를 위해서 Clustering 기능을 직접 구현한다고 생각해보자… 필자로서는 상상이 안가는 일이다.

담당자가 바뀌었을때도 안정적인 운영이 가능하다.
Framework을 만들어서 운영을 했다고 하자, 그후에 운영 담당 기술자가 바뀌면 그 Framework을 설명과 별도의 교육 작업이 필요하다. 그렇지만 J2EE 기술은 표준 기술이기 때문에 J2EE 기술을 가지고 있는 기술자를 뽑는다면 Framework 자체에 대한 기술 교육은 필요없이 바로 시스템을 인수 받을 수 있게 된다.

표준기술이기 때문에 많은 자료들을 구할 수 있다.
또한 잘 알다 싶이 J2EE는 이미 표준화되고 많은 검증된 솔루션(J2EE Pattern)과 Article들이 많기 때문에 EJB 솔루션을 사용하기 위한 도움을 받기가 용이하다.

RAD Tool을 통해서 개발 생산성을 극대화할 수 있다.
이미 EJB는 표준화된 기술이기 때문에 각종 RAD에서 EJB를 만들기 위한 Process를 자동화해서 지원하고 있다. 그래서 빠르게 EJB를 이용하여 프로그램을 제작할 수 있고 , RAD 이외에도 ant와 같은 command line tools를 이용해서도 개발에 도움을 받을 수 있다.

Tier 구분이 매우 편리하다.
Tier 구분은 위에서 말한 단순한 Servlet/JSP->Java Bean 이런 Tier 구분이 아니라, EJB는 Remote Call로 Invoke가 가능하기 때문에 Presentation (Servlet/JSP)와 Business Logic(EJB)을 물리적으로 완전히 분리하는것도 가능하다. 또한 Servlet/JSP가 아니라 Applet, RMI/IIOP를 이용하여 일반 Client까지 연동이 가능하기 때문에, Presentation Layer에 대해서 독립성을 가지는 Tier 모델을 작성할 수 있다.

그렇다면 EJB를 사용하는게 언제나 좋은가?

결론부터 이야기 하자면, 대답은 NO이다.
특히 가장 하고 싶은말중 하나는 EJB의 특징을 제대로 알고 필요한 요소에 제대로 사용하자는 것이다. ( 예를 들어 EJB의 Transaction 모델을 쓰면서 dbconn.commit()을 한다던지와 같은 일을 하는건 없어져야한다는 말이다. )

물론 EJB 기술이 쉬운 기술은 아니다.그러나 한국 IT 특성상 신기술을 따라가는 경향이 심한것 같다. EJB의 특징이나 문제점을 제대로 파악하지 않는 상태에서 EJB를 사용하는것은 오히려 득보다는 실이 많다.

RMI나 Beans 기술에 익숙하다면 이미 익숙한 기술을 사용하기 바란다. 프로젝트는 공부를 하기 위해서가 아니라, 이미 알고 있는 기술을 안정적으로 구현하는 것이 되어야 한다.


그외에도 JNI를 사용하는 구조나 Multithread 모델을 사용하는 구조, static 변수를 사용하는 구조를 EJB로 구현하는것은 해서는 안될일이다.

그리고 simple한 application을 굳이 EJB를 써서 구현할 필요는 없다. (EJB는 Deployment Descriptor도 만들어야하고, 생각보다 할일이 많다.)

결론적으로 EJB는 매우 유용한 Architecture이고 개발자가 해야할 많은 부분을 자동으로 처리해주는 안정화되고 최적화된 개발 framework이다. 그러나 EJB를 사용하기 위해서는 그에 알맞은 적절한 지식이 필요하며, 적재적소에 사용하지 않는 다면 득보다 실이 많을 수 있는 기술임을 인식하는것이 중요하다.

참고 자료 http://www.theserverside.com/articles/article.tss?l=Is-EJB-Appropriate

출처 블로그 > Don't Worry~ Be Happy!!
원본 http://blog.naver.com/swucs/40003014614


Posted by theYoungman
engineering/System Eng.2006. 8. 6. 23:30

EJB 는 왜 필요할까요?


EJB는 왜 필요할까요?
EJB는 "대규모이고 구조가 복잡한 분산 객체 환경"을 쉽게 구현하기 위해서 등장했습니다.
이것이 과거, 현재, 미래를 통틀어 EJB의 제 1 목표이고, 존재의 의미입니다.

따라서, EJB를 사용할 것인지 말 것인지에 앞서, 개발자들은 전체 아키텍쳐를 분산 객체 환경으로 가져갈 것인가 말 것인가를 고려해야 합니다. 만일, 분산 객체 환경이 필요 없다면, EJB를 써야 할 필요성의 70퍼센트는 감소됩니다.

그렇다면, 분산 환경은 왜 필요한걸까요?
분산 환경은 비즈니스 로직과 UI로직을 서로 다른 머신(또는 프로세스)로 분리시킴으로써 비즈니스 로직의 재사용성과 시스템 아키텍쳐의 유연성을 높이기 위해서 등장했습니다.
이 두 조건은 시스템이 커지고 복잡해질 수록 중요합니다. 그래서 대규모 시스템엔 분산 객체 아키텍쳐가 추천되는 것이고, 분산 객체 환경의 구축을 쉽게 하려다 보니 EJB와 같은 전용 플랫폼이
필요한 것입니다.

자, 그렇다면, EJB의 각 요소들과 기능들이 나오게 된 연유에 대해 좀 더 자세히 알아봅시다.

분산 환경을 쉽게 구현하게 하려다보니, RMI 가 필요합니다. 재사용성을 높이려다 보니 컴포넌트 형태가 적합합니다. 데이트 소스가 어떤 형태이든 간에 비즈니스 로직의 소스가 바뀌지 않게 하기 위해서는 비즈니스 로직 컴포넌트와 데이터베이스 접근 컴포넌트를 따로 나눌 필요가 있었습니다. 그래서 세션 빈이라는 것과 엔터티 빈이라는 것을 만들었습니다.

이들이 데이터베이스에 접근하는 컴포넌트이고, 만들기 쉽게, 재사용하기 쉽게 만들어야 하다보니
자연히 트랜잭션을 최대한 자동화할 필요가 생겼습니다. 그래서 트랜잭션 속성이란 걸 지정해서 트랜잭션을 관리하게 만들었습니다. 컴포넌트가 컴포넌트를 호출하다 보니, 컴포넌트 간에 트랜잭션을 전달하게 할 필요도 있습니다. 그래서, 그런 기능도 넣었습니다. 컴포넌트의 다양한 상태에 따라 사용자가 적절한 조치를 취할 수 있도록 콜백 메소드들도 넣었습니다. 자, 수정사항이 발생할 때마다 컴포넌트를 고치게 하는 것은 용이성, 재사용성의 규칙에 위배되므로, 굳이 로직으로 넣을 필요가 없는 것(비즈니스 로직이 아닌 것)은 설정파일에 담아, 소스 수정이 없이 설정만 하면 적용되도록 만들 필요가 있습니다. 그래서 배치 디스크립터란 설정 파일을 만들고, 그런 것들을 끌어
모아 몽땅 집어넣었습니다....etc....어라? UI 와 비즈니스 로직 컴포넌트 간에 네트웍을 통한 RMI 통신이 들어가고, 게다가 여러 개의 객체가 모여 하나의 컴포넌트를 이루며, 자동화를 위해 개발자 모르게 여러 로직을 실행시키게 하다 보니 이거 원 속도가 장난이 아니게 느리고, 자원을 지나치다 싶을 만큼 잡아먹습니다.
이렇게 무겁고 느린 걸 누가 삽니까. 자, 어떻게든 최대한 자원을 관리할 필요가 있습니다.
세션 빈을 상태유지 세션 빈과 무상태 세션 빈으로 나누고, 무상태 세션 빈 인스턴스는 풀링을 시켰습니다. 같은 맥락으로, 데이터 베이스 커넥션 풀링시키는 건 테크닉이라고 하기도 뭐할 만큼 일반적이며 필수적이므로 이 또한 포함시켰습니다.

자, 그럼 결론.

1. "속도를 위해 EJB를 사용한다?"

=> EJB의 여러 기능들은 "속도" 를 위해서 나온 것이 아니라, "분산 객체 환경" 에서 "개발유지보수의 편의성" 과 "시스템의 유연성"을 높이기 위해 고안되었습니다. "속도" 와 "개발유지보수편의성/시스템유연성"은 서로 반비례 그래프를 그리는 인자들입니다. "속도" 와 "편의성/유연성" 이 대치되어 이들 중 하나를 선택할 필요가 있을 때, EJB의 스펙이나 컨테이너 설계자들은 "편의성/유연성"을 택할것입니다.
따라서, 누군가가 "기능 구현을 위해 꼭 필요한 것은 아니지만, 속도를 높이기 위해 EJB를 끼워넣겠다" 라고 한다면 그는 EJB의 개발 의도를 잘못 이해한것이고, 따라서 심각한 오해를 하고 있다는 것을 말해두고 싶습니다.

2. "안정성을 위해 EJB를 사용한다?"

EJB는 이론적으로 안정성이 높습니다. 왜 그럴까요?

첫째 이유는, EJB가 좋은 프레임웍이기 때문입니다.
비즈니스 로직과 UI가 완전히 분리되어있으므로, 개발자들은 비즈니스 로직 담당자와 UI담당자로 나뉘게 됩니다. 각 개발자들의 관심의 범위가 1/2로 좁아지게 되는 만큼 이들은 각각의 영역에 대해 심리적, 지식적으로 2배만큼 전문화됩니다.
전문가들이 만든 코드는 일관성과 안정성을 갖게 되죠. 또한, 잦은 로직 수정 요구가 있더라도 보다 적은 부분을 수정함으로써, 짧은 시간에, 안정적으로 요구를 반영할 수 있습니다.
또한, EJB는 프로그래밍 상의 제한점을 많이 두었기 때문에(예를 들어 하나의 컴포넌트 인스턴스를 동시에 두 명의 사용자가 사용하지 못한다든지 하는...) 개발자의 실수를 미연에 방지하는 역할도 합니다. (안정성을 저해하는 가장 큰 요인은 설계/개발자의 무지와 OS 및 엔진 역할을 하는 소프트웨어의 버그 때문이라는 거 아시죠?)

둘째, EJB는 3계층의 미들티어에 위치하면서, 한정된 공유자원들 (예를 들어, 데이터 베이스 커넥션)을 효과적으로 관리해줍니다. 이것은 사용자가 많을 경우의 안정성에 지대한 영향을 미치는 요인입니다.

그러나, EJB를 끼워넣어야만 이것이 가능한 것은 아닙니다. 웹서버(WAS포함)와 데이터베이스만으로 이루어지는 구조에서, WAS 즉, 서블릿/JSP 엔진은 데이터베이스 커넥션 풀링이라든지 스레드 풀링등을 통해 나름대로 공유자원을 최대한 활용하는 메커니즘을 제공해 줍니다.

세째, 기본적으로 EJB가 들어가면, 머신은 WebServer단 + EJB 단 + DB 단으로 보통 3계층화 됩니다.
WebServer 단 + DB 단으로 이루어지는 2계층에 비해 머신이 1대 더 많죠. 즉, 한 대의 머신이 UI 와 비즈니스 로직을 모두 처리하는 대신, 두 대의 머신이 비즈니스 로직과 UI를 나눠서 처리하므로 2계층 환경에 비해 더 많은 사용자를 수용할 수 있습니다.

어라? 그럼, EJB서버로 쓸 예정이던 머신을 WebServer 머신으로 쓰고, 2개의 WebServer 머신을 클러스터링 시키면 어떨까?
네, 좋습니다. RMI 와 컴포넌트를 사용하지 않으므로, 같은 수의 사용자에 대해서 이 구조는 자원을 보다 덜 소모합니다. 이는 바꿔 말하면, 같은 양의 자원으로 보다 많은 사용자를 수용할 수 있다는 뜻입니다.
또한, WebServer + EJB 서버 각각 한 대로 된 구조는 클러스터링이 되어있지 않습니다.
클러스터링을 시키려면 각 티어마다 머신을 한 대씩 더 두어서 총 4대의 머신을 마련해야 하죠.
그러나, EJB를 안쓰면 웹서버 단이 두 대가 되므로 이들은 자연스레 클러스터링을 구성할 수 있습니다. 즉, 동일한 물리적 환경에서 이 구조는 페일오버가 된다는 얘기죠. 이렇게 보면, EJB를 쓰지 않은 구조는 오히려 훨씬 안정적인 아키텍쳐가 됩니다.


결론적으로, 분산 객체 환경이 필요하지 않다면, EJB를 쓰는 구조가 쓰지 않는 구조에 비해 갖는 이점은 "좋은 프레임웍을 제공" 한다는 것 뿐입니다.

일, 비즈니스 로직과 UI를 완전히 분리시킬 수 있는 좋은 프레임웍이 있다면 EJB를 사용하지 않고,
WebServer 티어 (아...물론, 이 글에서 WebServer 티어라 하는 것은 , JSP 와 서블릿을 포함하여 말합니다.
정확히 말하면, WebServer + WAS를 말한다는 거죠.) 에 모든 것을 두는 것이 안정성이 더욱 높습니다.


3. 더하여, "EJB는 배우기 쉽고, 사용하기 쉽다" 라는 말씀들을 많이 하시는데...그건, CORBA라든지 하는 다른 분산객체용 엔진에 비해 그렇다는 것입니다.
EJB를 능숙하게 사용하려면 적잖은 시간이 걸립니다. 한 일주일 교육받는 걸로 충분한 문제가 아니라는 거죠. 그렇다고, EJB에 대해 철저히 알지 못하고 사용하시는 것은 오히려 사용하지 않는 것만 못합니다.

이는 오히려 개발자의 무지로 인해 시스템의 안정성과 유지/보수의 용이성을 해치게 되죠. 그리고, 나중에 튜닝한다고 시간을 더 뺏기게 될 수도 있습니다. 필요한 만큼 머신을 구입할 수 있는 상황이 안되는 그런 경우에, 성능이 기대만큼 안 나오면 어쩔 수 없이 튜닝작업 들어가야 하지 않겠습니까? 아다시피, 어플리케이션의 정확한 속도는 테스트를 해봐야 아는 거고 보다 정확한 테스트는 개발이 어느 정도 완료된 후에야 할 수 있는 거죠. 그러다보니, 튜닝할 시간은 짧고, 그래서 꼼수에 꼼수를
더해가는 하는 거죠. 이거...쥐약이죠. 잘 만들어 놓은 어플리케이션을 끝에 가서 완전히 꼬아놓을 수도 있습니다. 흔히 말하는 "스파게티 소스" 가 되는거죠. 스파게티 소스에서 안정성을 기대할 수 있겠습니까? 절대 아니죠.

결론적으로, 님의 환경이 어떻든간에 즉, 트랜잭션이 얼마나 많고, 레코드가 얼마나 많건간에 "분산 객체 아키텍쳐"가 필요치 않고, 좋은 프레임웍을 갖고 계시다면, EJB는 넣지 않으시는 것이 좋습니다. 그렇지 않다면, 즉, "분산 객체 아키텍쳐"가 필요하다거나, 좋은 프레임웍이 없다거나, 능숙한 설계/개발자가 없다거나 하실 경우는 EJB가 적극 추천됩니다.

물론, 어플리케이션 개발 후, 성능 테스트의 결과에 따라, 머신은 WebServer 만 사용할 때보다 1.5 내지 2 배정도 증설하실 여력이 있다면 말입니다.


출처 블로그 > 숨쉬는 일보다 니가 더 익숙했던 난
원본 http://blog.naver.com/celestialorb/40004374985


Posted by theYoungman

티스토리툴바