Enterprise JavaBeans에 대한 초보자 가이드

EJB (Enterprise JavaBeans)는 1998 년 3 월 Enterprise JavaBeans 사양 버전 1.0이 발표 된 이후 많은 관심을 불러 일으켰습니다 . Oracle, Borland, Tandem, Symantec, Sybase 및 Visigenic과 같은 회사는 EJB 사양을 준수하는 제품을 발표 및 / 또는 제공했습니다. 이번 달에는 Enterprise JavaBeans가 정확히 무엇인지 자세히 살펴 보겠습니다. EJB가 원래의 JavaBeans 구성 요소 모델과 어떻게 다른지 살펴보고 EJB가 왜 그렇게 엄청난 관심을 불러 일으켰는지 논의 할 것입니다.

그러나 먼저 권고 사항입니다. 이번 달에는 소스 코드 나 방법에 대한 주제를 다루지 않을 것입니다. 이 기사는 튜토리얼이 아닙니다. 오히려 아키텍처 개요입니다. EJB는 많은 영역을 다루며 관련된 기본 개념을 먼저 이해하지 않으면 코드 스 니펫과 프로그래밍 트릭은 의미가 없습니다. JavaWorld 독자 의 관심이 있다면 향후 기사에서 Enterprise JavaBeans API를 사용하여 고유 한 Enterprise JavaBeans를 만드는 방법에 대해 설명 할 수 있습니다.

EJB가 개발자에게 왜 그렇게 매력적인 지 이해하려면 역사적 배경이 필요합니다. 먼저 클라이언트 / 서버 시스템의 역사와 현재 상황을 살펴 보겠습니다. 그런 다음 EJB 시스템의 다양한 부분에 대해 설명합니다 . EJB 서버 내부에서 실행 되는 EJB 컨테이너상주 하는 EJB 구성 요소 와 클라이언트가 EJB 구성 요소의 일종의 "원격 제어"로 사용하는 EJB 객체 . 세션엔티티 객체 라는 두 가지 유형의 EJB를 살펴 보겠습니다 . 당신은 또한 원격 에 대해 읽을 것입니다인터페이스는 EJB 인스턴스를 생성하고 각각 EJB의 비즈니스 메소드에 대한 액세스를 제공합니다. 이 기사가 끝나면 Enterprise JavaBeans를 사용하여 확장 가능한 서버를 구축하는 방법에 대한 아이디어를 얻게 될 것입니다. 하지만 먼저 시간을 거슬러 올라갑니다.

클라이언트 / 서버 기록

고대 역사

처음에는 메인 프레임 컴퓨터가있었습니다. 그리고 좋았습니다. (또는 어쨌든 좋은 것입니다.) 1960 년대까지 정보 처리의 최첨단은 주로 대규모 조직에서 일상적인 비즈니스 운영을 지원하기 위해 사용하는 크고 값 비싼 기계로 구성되었습니다. 1970 년대 미니 컴퓨터와 시분할은 컴퓨팅 능력의 접근성을 높였지만 정보와 처리는 여전히 개별 기계에 집중되어있었습니다. 1980 년대 최초의 개인용 컴퓨터는 수천 개의 작은 정보 섬으로 빠르게 기업 환경을 뒤덮었 고, 모두 지칠 줄 모르는 품질 보고서를 쏟아 내고 충돌시 중요한 데이터를 잃고 빠르게 서로 일치하지 않게되었습니다.

구출 할 클라이언트 / 서버

클라이언트 / 서버 아키텍처는 중앙 집중식 데이터 제어 및 광범위한 데이터 접근성에 대한 요구를 처리하는 방법에 대한 가장 일반적인 솔루션 중 하나입니다. 클라이언트 / 서버 시스템에서 정보는 상대적으로 중앙 집중화되어 (또는 분산 서버간에 분할 및 / 또는 복제 됨) 데이터의 제어 및 일관성을 용이하게하는 동시에 사용자가 필요로하는 데이터에 대한 액세스를 제공합니다.

클라이언트-서버 시스템은 이제 일반적으로 다양한 수의 계층 으로 구성 됩니다. 사용자 인터페이스가 데이터베이스 및 비즈니스 애플리케이션과 동일한 컴퓨터에서 실행되는 표준 구형 메인 프레임 또는 시분할 시스템을 단일 계층이라고합니다. 이러한 시스템은 비교적 관리하기 쉽고 데이터가 한 곳에만 저장되기 때문에 데이터 일관성이 간단합니다. 안타깝게도 단일 계층 시스템은 확장 성이 제한되어 있으며 특히 통신이 관련된 경우 가용성 위험이 발생하기 쉽습니다 (한 컴퓨터가 다운되면 전체 비즈니스가 다운 됨).

첫 번째 클라이언트 / 서버 시스템은 2 계층으로, 사용자 인터페이스는 클라이언트에서 실행되고 데이터베이스는 서버에서 실행되었습니다. 이러한 시스템은 여전히 ​​흔합니다. 한 종류의 2 계층 서버는 클라이언트에서 대부분의 비즈니스 로직을 수행하여 SQL 스트림을 서버로 전송하여 공유 데이터를 업데이트합니다. 클라이언트 / 서버 대화가 서버의 데이터베이스 언어 수준에서 발생하기 때문에 이것은 유연한 솔루션입니다. 이러한 시스템에서는 서버가 트랜잭션을 수행하는 데 필요한 데이터베이스 스키마 (테이블, 뷰 등)에 액세스 할 수있는 한 서버를 수정하지 않고 새로운 비즈니스 규칙 및 조건을 반영하도록 올바르게 설계된 클라이언트를 수정할 수 있습니다. 이러한 2 계층 시스템의 서버를 아래와 같이 데이터베이스 서버 라고 합니다.

그러나 데이터베이스 서버에는 약간의 책임이 있습니다. 종종 특정 비즈니스 기능 (예 : 주문에 항목 추가)에 대한 SQL은 호출마다 업데이트되거나 삽입되는 데이터를 제외하고 동일합니다. 데이터베이스 서버는 각 비즈니스 기능에 대해 거의 동일한 SQL을 구문 분석하고 다시 구문 분석합니다. 예를 들어, 주문에 항목을 추가하기위한 모든 SQL 문은 데이터베이스에서 고객을 찾기위한 SQL 문과 마찬가지로 매우 유사합니다. 이 구문 분석에 걸리는 시간은 실제로 데이터를 처리하는 데 더 많이 소비됩니다. (SQL 구문 분석 캐시 및 저장 프로 시저를 포함하여이 문제에 대한 해결책이 있습니다.) 발생하는 또 다른 문제는 클라이언트와 데이터베이스를 동시에 버전 화하는 것입니다. 업그레이드를 위해 모든 시스템을 종료해야합니다.소프트웨어 버전이 뒤처진 클라이언트 또는 서버는 일반적으로 업그레이드 될 때까지 사용할 수 없습니다.

애플리케이션 서버

응용 프로그램 서버 는 데이터베이스 서버가 가지고있는 문제들을 해결하기 때문에 아키텍처 (다음 이미지 참조) 데이터베이스 서버 아키텍처에 인기있는 대안입니다.

데이터베이스 서버 환경은 일반적으로 클라이언트에서 비즈니스 메소드를 실행하고 대부분 지속성 및 데이터 무결성 강화를 위해 서버를 사용합니다. 애플리케이션 서버에서 비즈니스 메소드는 서버에서 실행되고 클라이언트는 서버가 이러한 메소드를 실행하도록 요청합니다. 이 시나리오에서 클라이언트와 서버는 일반적으로 테이블 및 행 수준이 아닌 비즈니스 트랜잭션 수준에서 대화를 나타내는 프로토콜을 사용합니다. 이러한 애플리케이션 서버는 종종 데이터베이스 서버보다 성능이 더 우수하지만 여전히 버전 관리 문제가 있습니다.

아키텍처에 계층을 추가하여 데이터베이스와 애플리케이션 시스템을 모두 향상시킬 수 있습니다. 소위 3 계층 시스템은 클라이언트와 서버 사이에 중간 구성 요소를 배치합니다. 전체 산업 (미들웨어)이 2 계층 시스템의 책임을 해결하기 위해 성장했습니다. 트랜잭션 처리 모니터,한 가지 유형의 미들웨어는 여러 클라이언트로부터 요청 스트림을 수신하고 여러 서버 간의로드 균형을 조정하고 서버 장애시 장애 조치를 제공하며 클라이언트를 대신하여 트랜잭션을 관리 할 수 ​​있습니다. 다른 유형의 미들웨어는 통신 프로토콜 변환을 제공하고, 클라이언트와 여러 이기종 서버 간의 요청 및 응답을 통합하고 (특히 비즈니스 프로세스 리엔지니어링에서 레거시 시스템을 처리 할 때 널리 사용됨) 서비스 측정 및 네트워크 트래픽 정보를 제공합니다.

다중 계층은 유연성과 상호 운용성을 제공하여 이러한 3 개 이상의 서비스 계층이있는 시스템을 만듭니다. 예를 들어, n 계층 시스템은 3 계층 시스템의 일반화로, 각 소프트웨어 계층은 위와 아래 계층에 서로 다른 수준의 서비스를 제공합니다. n 계층 관점에서는 클라이언트가 단일 서버에 액세스하는 단순한 수단이 아니라 네트워크를 분산 서비스 풀로 간주합니다.

객체 지향 언어와 기술이 유행함에 따라 클라이언트 / 서버 시스템이 점점 객체 지향으로 이동하고 있습니다. CORBA (Common Object Request Broker Architecture)는 애플리케이션 내의 개체 (다른 언어로 작성된 개체도 포함)가 주어진 애플리케이션의 필요에 따라 별도의 시스템에서 실행될 수 있도록하는 아키텍처입니다. 몇 년 전에 작성된 애플리케이션은 CORBA 서비스로 패키징 될 수 있으며 새로운 시스템과 상호 운용됩니다. CORBA와 호환되도록 설계된 Enterprise JavaBeans는 객체 지향 애플리케이션 서버 링의 또 다른 항목입니다.

이 기사의 목적은 클라이언트 / 서버 시스템에 대한 튜토리얼을 제공하는 것이 아니라 컨텍스트를 정의하기 위해 약간의 배경 지식을 제공하는 것이 필요했습니다. 이제 EJB가 제공해야하는 것을 살펴 보겠습니다.

Enterprise JavaBeans 및 확장 가능한 애플리케이션 서버

이제 우리는 약간의 역사를 살펴보고 애플리케이션 서버가 무엇인지 이해 했으므로 Enterprise JavaBeans를 살펴보고 해당 컨텍스트에서 제공하는 내용을 살펴 보겠습니다.

Enterprise JavaBeans의 기본 개념은 서버에 "플러그인"될 수있는 구성 요소에 대한 프레임 워크를 제공하여 해당 서버의 기능을 확장하는 것입니다. Enterprise JavaBeans는 유사한 개념을 사용한다는 점에서 원래 JavaBeans와 유사합니다. EJB 기술은 JavaBeans 구성 요소 사양이 아니라 완전히 다른 (그리고 방대한) Enterprise JavaBeans 사양에 의해 관리됩니다. (이 사양에 대한 자세한 내용은 리소스를 참조하십시오.) EJB 사양 은 EJB 클라이언트 / 서버 시스템의 다양한 플레이어를 호출하고, EJB가 클라이언트 및 기존 시스템과 상호 운용되는 방식을 설명하고, CORBA와 EJB의 호환성을 설명하고, 다음에 대한 책임을 정의합니다. 시스템의 다양한 구성 요소.

Enterprise JavaBeans 목표

EJB 스펙은 한 번에 여러 목표를 달성하려고 :

  • EJB는 개발자가 애플리케이션을 쉽게 만들 수 있도록 설계되어 트랜잭션, 스레드,로드 밸런싱 등을 관리하는 저수준 시스템 세부 사항에서 해방합니다. 애플리케이션 개발자는 비즈니스 로직에 집중하고 데이터 처리 관리에 대한 세부 사항을 프레임 워크에 맡길 수 있습니다. 그러나 특수한 응용 프로그램의 경우 항상 "내부"로 들어가 이러한 하위 수준 서비스를 사용자 정의 할 수 있습니다.

  • EJB 사양은 EJB를 프레임 워크의 주요 구조를 정의하고 특히 그들 사이의 계약을 정의합니다. 클라이언트, 서버 및 개별 구성 요소의 책임이 모두 명확하게 설명되어 있습니다. (이 구조가 무엇인지 잠시 살펴 보겠습니다.) Enterprise JavaBean 구성 요소를 생성하는 개발자는 EJB 호환 서버를 생성하는 사람과 매우 다른 역할을하며 사양은 각각의 책임을 설명합니다.

  • EJB는 클라이언트 / 서버 애플리케이션이 Java 언어로 구축되는 표준 방식이되는 것을 목표로합니다. 다른 공급 업체의 원래 JavaBeans (또는 Delphi 구성 요소 등)를 결합하여 사용자 지정 클라이언트를 생성 할 수있는 것처럼 다른 공급 업체의 EJB 서버 구성 요소를 결합하여 사용자 정의 서버를 생성 할 수 있습니다. Java 클래스 인 EJB 구성 요소는 물론 재 컴파일없이 EJB 호환 서버에서 실행됩니다. 이는 플랫폼 별 솔루션이 제공 할 수없는 이점입니다.

  • 마지막으로 EJB는 다른 Java API와 호환되고 사용되며, 비 Java 앱과 상호 운용 될 수 있으며 CORBA와 호환됩니다.

EJB 클라이언트 / 서버 시스템의 작동 방식

EJB 클라이언트 / 서버 시스템이 작동하는 방식을 이해하려면 EJB 시스템의 기본 부분 인 EJB 구성 요소, EJB 컨테이너 및 EJB 개체를 이해해야합니다.

Enterprise JavaBeans 컴포넌트

Enterprise JavaBean은 전통적인 JavaBean과 같은 구성 요소입니다. Enterprise JavaBeans는 EJB 컨테이너 내 에서 실행되며 차례로 EJB 서버 내에서 실행됩니다 . EJB 컨테이너를 호스팅하고 필요한 서비스를 제공 할 수있는 모든 서버는 EJB 서버가 될 수 있습니다. (즉, 많은 기존 서버가 EJB 서버로 확장 될 수 있으며 실제로 많은 공급 업체가이를 달성했거나 그렇게 할 의사를 발표했습니다.)

EJB 구성 요소는 "Enterprise JavaBean"으로 간주 될 가능성이 가장 높은 EJB 클래스 유형입니다. 비즈니스 로직을 구현하는 EJB 개발자가 작성한 Java 클래스입니다. EJB 시스템의 다른 모든 클래스는 클라이언트 액세스를 지원하거나 EJB 구성 요소 클래스에 대한 서비스 (예 : 지속성 등)를 제공합니다.

Enterprise JavaBeans 컨테이너

EJB 컨테이너는 EJB 구성 요소가 "존재하는"곳입니다. EJB 컨테이너는 트랜잭션 및 리소스 관리, 버전 관리, 확장 성, 이동성, 지속성 및 보안과 같은 서비스를 포함 된 EJB 구성 요소에 제공합니다. EJB 컨테이너는 이러한 모든 기능을 처리하므로 EJB 구성 요소 개발자는 비즈니스 규칙에 집중할 수 있으며 데이터베이스 조작 및 기타 세부 정보를 컨테이너에 맡길 수 있습니다. 예를 들어, 단일 EJB 구성 요소가 현재 트랜잭션을 중단해야한다고 결정하면 해당 컨테이너에 간단히 알려줍니다 ( EJB 사양에 정의 된 방식으로 컨테이너는 모든 롤백을 수행하거나 취소하는 데 필요한 모든 작업을 수행합니다. 트랜잭션이 진행 중입니다. 일반적으로 단일 EJB 컨테이너 내에 여러 EJB 구성 요소 인스턴스가 있습니다.

EJB 객체 및 원격 인터페이스

클라이언트 프로그램은 EJB 객체 를 통해 원격 EJB에서 메소드를 실행 합니다. EJB 개체는 서버에서 EJB 구성 요소의 "원격 인터페이스"를 구현합니다. 원격 인터페이스는 EJB 구성 요소의 "비즈니스"메소드를 나타냅니다. 원격 인터페이스는 주문 양식을 작성하거나 환자를 전문가에게 연기하는 것과 같은 EJB 개체의 실제적이고 유용한 작업을 수행합니다. 아래에서 원격 인터페이스에 대해 자세히 설명합니다.