ejb와javaBean의 차이 및 응용 장소

EJB의 장단점.

2010-06-12 13:45:40 | 카테고리: EJB | 바이트 구독
이 글은 EJB를 자신의 기술 프로젝트에 적용하려는 목적을 담고 있다.그러면 EJB를 사용하기 전에 Ejb의 장단점을 살펴보고 언제 EJB를 사용해야 하는지, 언제 EJB를 사용하지 말아야 하는지를 요약해 봅시다.EJB의 장점 1 규범 상세성: EJB는 규범성을 바탕으로 하는 기술이다.(이것은 EJB의 주요 장점과 단점을 동시에 구성한다.)EJB 규범 설명서에는 데이터 유형, 구성 요소 설명 주기, 역할 분포 및 기타 응용 프로그램 실행의 여러 가지 측면이 설명되어 있습니다.2와 J2EE의 긴밀한 통합: 많은 서버 기술이 J2EE를 중심으로 구축되었다. 그 중에서 EJB와 기타 관련 기술, 예를 들어 servlets, JavaServer Pages, Java Message Service, J2EE 연결기 구조, Java 데이터베이스 연결, Java Authentication, Authorization Service, Java Transaction API, JavaMail 기술 등이 있다.이러한 기술은 J2EE와 EJB를 유기적으로 결합시켜 매우 매력적인 해결 방안을 구성한다.3 좋은 신축성: 응용 프로그램 서버가 대부분의 자원 관리 기능을 통과하기만 하면 개발상들은 더욱 복잡한 신축 알고리즘을 응용할 수 있다.4 자원 관리 시스템을 사용할 권리가 있습니다. EJB 용기와 함께 수천 줄의 코드를 얻어 관리 자원에 접근할 수 있습니다. 사무 관리 시스템, 안전 관리 시스템, 디렉터리 서비스를 포함합니다.EJB가 있기 때문에 우리가 직접 이룬 이 부분을 아낄 수 있다.EJB의 단점 EJB의 장점은 탁월하지만 단점과 장점은 똑같이 현저하다. 1 거대하고 복잡한 규격 설명: 복잡한 분포식 시스템에 대해 하나의 문서를 설명하는 것은 매우 합리적인 일이다.그러나 모든 문서 정보가 진정으로 필요한 것은 아니다. EJB의 문서는 오히려 매우 불편한 도구가 되었다.2 방대한 파일: 프로젝트를 개발하기 전에 1000여 페이지의 문서를 읽어야 합니다.이것은 EJB를 배치할 때 매우 고통스러운 일이다.3 프로그램 디버깅 시간 증가: 일반적인 자바 코드를 사용하는 것보다 EJB 솔루션을 만드는 데 걸리는 시간이 길고, EJB 프로그램을 디버깅하는 데도 일반적인 자바 코드를 디버깅하는 데 걸리는 시간도 길다.주요 원인은 버그가 코드 자체에서 나오는지 용기에서 나오는지 모르기 때문이다.4 EJB 코드는 더욱 복잡합니다. 예를 들어 세션 bean을 실현하기 위해서는 세 개의 클래스를 써야 합니다. 실체 bean을 실현하기 위해서는 네 개의 클래스를 써야 합니다.예를 들어 가장 간단한'Hello world'프로그램은 파일이 아니라 10개의 파일을 필요로 한다.5 중복 설계의 위험: 이런 결과를 초래하는 원인은 복잡한 문서 때문이다.만약 네가 EJB의 개념을 완전히 이해하지 못한다면, 너는 그것을 노예로 삼아 네가 쓰게 하고, 반대로 네가 힘들게 하지 않을 것이다.6 유지 보수의 어려움: EJB는 끊임없이 갱신되는 기술입니다. 신기술이 끊임없이 출시될 때 코드를 업그레이드해야 합니다. 그러면 프로그램과 새로운 EJB 용기를 호환하기 위해 추가 노력과 비용이 필요합니다.
 
언제 EJB를 사용해야 할지 많은 장점과 단점 앞에서 프로그래머는 선택할 수 없는 것 같다. 이런 상황에 근거하여 우리는 언제 EJB를 사용하는 것이 더 적합한지 어떻게 결정해야 하는가?만약 servlet 기반의 웹 응용 프로그램이 있다면, 이 응용 프로그램은 데이터베이스에 사용해야 합니다.JDBC에 사용하려면 SQL 조회 문장을 사용하고 ResultSet 대상을 받아야 합니다. 이것은 업무 논리 대상을 나타내는 데이터입니다.데이터베이스에 기록된 구조를 표현하기 위해 클래스를 만들 것입니다.코드는 다음과 같습니다.

MyObjectobj = new MyObject();  obj.setXXX(rs.getString("XXX"));  obj.setYYY(rs.getString("YYY")); 
  

결과 집합을 표현층에 표시하거나 표현층 데이터에서 데이터베이스에 삽입하면 이 논리적 업무를 나의 My Object로 옮기는 방법을 고려할 것이다.servlet과 JDBC 링크의 세부 사항을 분리하면 그 대상이 데이터베이스에서 자신을 조회하고 수정하고 삭제합니다.이제 새로운 문제가 생길 것이다. 어떻게 조회 문장을 통해 데이터베이스에서 대상을 찾을 수 있습니까?메인 키를 통해 찾으려면 메인 키를 클래스의 구조기에 전달해야 합니다.여러 조건을 통해 기록을 찾으려면 더 많은 정적 방법이 필요할 것이다.너도 사무 처리를 지원하는 방식이 필요하다.응용 프로그램에 접근하는 사람이 많아지고 프로그램의 압력이 커지며 프로그램의 안정성도 중요해질 때 복제(replication), 빠른 대상 지속화(fast object persistence), 대상 버퍼링(object caching), 데이터베이스 연결 탱크(database connection pools), 보안 업무(secure transactions) 등을 고려해야 한다.이 문제들은 EJB에서 모두 해결되었다.너는 더 이상 시행착오를 범할 필요가 없다.만약 당신의 bean이 용기 관리 지속력 (Container Managed Persistence) 실체 bean이라면, 당신이 해야 할 일은 인터페이스를 실현하는 것입니다. 데이터베이스 연결 문제를 고려할 필요가 없습니다.만약 이것이 당신이 필요로 하는 것이 아니더라도 상관없다면, 당신은 스스로 BMP(Bean Managed Persistence) 실체 bean을 실현할 수 있습니다.응용 프로그램의 사무층에서 데이터를 유지하는 대상이 아니라 일부 동작 기능을 실현하는 대상도 있는데 이런 대상은 업무 논리를 나타낸다.프로그램을 쓰기 시작할 때, 모든 업무 논리가 servlet에 들어갈 것입니다.응용 프로그램은 최종적으로 몇 개의 servlets의 지원을 필요로 할 뿐만 아니라, 복사 업무 논리 코드를 붙일지, 아니면 단독으로 하나의 클래스라고 할지 선택할 것입니다.일부 사용자는 최종적으로 모든 페이지에서 응용 프로그램과 상호작용을 하기 때문에 그의session 정보를 저장하여 서로 다른 사용자의 요청 정보를 구별해야 한다.이 문제의 해결 방안은 세션 빈(Session Bean)이라고 하는데 응용 프로그램의 모든 업무 논리에 봉인될 것이다.EJB를 사용할 필요가 없는 경우 EJB는 뛰어난 기술이지만 모든 솔루션에 적합한 것은 아닙니다.EJB 는 보안, 지속성, 트랜잭션 지원 등 여러 가지 우수한 기능을 제공하지만, 모든 응용 프로그램이 이 기능을 필요로 하는 것은 아니다.또한 일부 비분포식 응용 프로그램에서는 안전, 업무가 아니라 속도에 더 많은 관심을 갖는다. 이럴 때 EJB를 사용하여 기업 개발을 할 필요가 없다.EJB의 분포식 특성 때문에 데이터는 클라이언트와 EJB 구성 요소(또는 서버) 사이에 있어야 합니다. 먼저marshalled, 그리고 unmarshalled입니다.이 특성은 대량의 손실을 도입하여 성능을 떨어뜨린다. 이것은 왜 같은 가상 기기에서 로컬 클래스를 사용하는 것이 더 좋은 선택인가이다.EJB에 대한 부적절한 견해 1 EJB는 비싼 기술이다. 이 대답은 너무 일방적이다.비록 현재 저가나 무료 응용 서버가 많이 발표되었지만, 이 서버들은 상업 서버의 모든 성능을 가지고 있다.그러나 한 대기업의 응용 프로그램 프로젝트에서 전체 프로젝트의 비용에 비해 응용 프로그램 서버의 가격은 그 중의 일부분에 불과하다.2 CMP bean을 사용할 때 SQL 지식을 알아야 한다. 이런 견해도 정확하지 않다.3 EJB 응용 프로그램은 서로 다른 용기 사이에서 쉽게 이식할 수 있다.이런 견해는 부분적으로 정확하다.EJB 코드가 하나의 portable 방식으로 쓰여야 합니다.Session beans와 BMP beans는 이식하기 쉬우나 CMP를 이식하는 것은 쉽지 않고 힘들다.4 실체 beans의 운행이 매우 느리다: 이 말은 대부분 옳다.대부분의 경우, 실체 bean의 운행이 매우 느리므로, 이를session bean으로 바꾸는 것이 가장 좋다.결론은 프로젝트에서 EJB 기술을 사용할지 결정하기 전에 응용 프로그램의 수요와 응용 프로그램의 발전 전망을 알아야 한다. 또한 EJB의 주요 목적지와 결함 원문 주소를 알아야 한다.http://tech.it168.com/j/n/2007-07-17/200707171548937.shtml
 
 
그리고 EJB와 자바빈의 차이점까지.
EJB는 일반적인 JavaBean이 아니다. EJB는 기업급 JavaBean이다. EJB는 모두 3가지로 나뉘는데 실체 Bean, 소식 Bean, 회화 Bean이다. EJB를 쓰는 데는 일정한 규범을 따라야 한다. 구체적인 규범은 관련 자료를 참고할 수 있다.또한 EJB를 실행하려면 상응하는 EJB 용기, 예를 들어 Weblogic, Jboss 등이 필요하지만 JavaBean은 필요하지 않고 Tomcat만 설치하면 된다.EJB는 서버 애플리케이션 개발에 사용되고 JavaBeans는 클라이언트 애플리케이션 개발에 사용됩니다.자바빈스를 사용하여 서버 응용 개발을 할 수도 있지만 자바빈스 모델은 서비스 프레임워크를 제공하지 않아 응용이 시스템급 서비스(예를 들어 사무관리, 안전성, 생명주기 관리 등)를 사용해야 할 때 적합하지 않다.  2.EJB 부품은 배치할 수 있습니다. EJB 부품은 독립된 단원으로 EJB 응용 서버에 배치할 수 있습니다. 응용 부품(application components)이고 Java Beans 부품은 배치할 수 없습니다. Java Beans 부품은 개발 부품으로 독립된 단원으로 배치할 수 없습니다.  3.EJB 구성 요소는 맞춤형 배치가 가능한 것으로 배치 설명서를 사용하면 EJB를 배치할 때 실행할 때 설정을 맞춤형으로 할 수 있지만 자바빈스 구성 요소는 배치할 때 맞춤형으로 할 수 없다. 자바빈스 구성 요소의 맞춤형은 개발 단계에서만 발생하고 개발 도구를 이용하여 자바빈스 구성 요소를 만들고 조립할 수 있을 뿐 배치할 때 맞춤형으로 할 수 없다.EJB 위젯은 분포식 대상으로 고객 응용 프로그램이나 다른 EJB 위젯에 의해 원격 접근을 할 수 있지만 JavaBeans 위젯은 분포식 대상이 아니다. JavaBeans 위젯은 구성된 응용 프로그램에서만 사용할 수 있고 원격 접근 능력을 제공할 수 없다.EJB 위젯은 터미널 사용자에게 보이지 않고 서버에서 실행되며 인간과 기계의 상호작용 인터페이스가 없고 일부 JavaBeans 위젯은 터미널 사용자에게 보인다. 예를 들어 GUI 응용 프로그램에서 사용하는 단추 위젯