자바 애플리케이션 미들웨어의 현황, Part 1

클라이언트 / 서버가 작동하지 않습니다. 새로운 인터넷 기반 기술이 번성하고있는 지금은 소문입니다. 그러나 이러한 새로운 기술은 더 새롭고 개방적인 프로토콜로 구현되고 더 큰 확장 성, 관리 용이성 및 다양성을 제공하도록 설계된 이전 접근 방식의 자연스러운 진화 일뿐입니다.

이 진화의 규모는 놀랍습니다. 대부분의 주요 클라이언트 / 서버 공급 업체는 제품을 현대화했으며 이제 마케팅 비용을 3 계층 기술로 전환합니다. 대부분의 경우 최신 제품은 Java 중심 및 인터넷 프로토콜 중심입니다. 예를 들어, 저는 마지막으로 최소 46 개의 Java 미들웨어 제품을 식별했습니다. 2 년 전에는 그 숫자의 절반을 찾기가 어려웠을 것입니다.

이것은 현재 형태로 범용 자바 미들웨어를 설명하는 2 부작 시리즈 중 첫 번째입니다. 이 첫 번째 기사에서는 현재 제품의 기능을 검토하고 이러한 기능이 중요한 이유를 설명합니다. 두 번째 부분에서 Anil Hemrajani는 EJB (Enterprise JavaBeans)를 검토하고 현재 세대의 Java 미들웨어 제품이이 중요한 구성 요소 표준과 관련되고 지원하는 방식을 보여줍니다.

배경

먼저 Java 미들웨어를 정의 해 보겠습니다 .이 용어는 BEA WebLogic과 같은 애플리케이션 서버, Active Software의 ActiveWorks 및 Push Technologies의 SpiritWAVE와 같은 메시징 제품, DBMS 레거시를 기반으로 구축되고 서버 기반 Java 개체 실행 기능을 추가하는 하이브리드 제품을 포함합니다. 응용 프로그램 서버와 같은 더 좁은 세그먼트에 집중할 수 있었지만이 범주에 정확히 맞지 않는 많은 제품에는 불공평 할 수 있지만 그럼에도 불구하고 다중 계층 응용 프로그램에는 고려해야합니다. 또한 응용 프로그램 서버 간에도 주로 서블릿 서버 인 서버와 ORB 기반 또는 OODB 기반 서버를 포함하여 상당한 스펙트럼이 있습니다. 이 모든 제품 사이에 선을 그리는 것은 점점 더 어려워집니다. 그러나 통합 기능은그들은 모두 Java 및 인터넷 기술을 사용하여 다중 계층 응용 프로그램 배포 문제를 해결하려고합니다.

미들웨어에서 Java를 사용하는 비즈니스 사례는 설득력이 있습니다. Java 미들웨어가 제공하는 이점은 다음과 같습니다.

  • 사무실과 조직을 경제적으로 상호 연결하는 인터넷 기능

  • 조직이 데이터 및 비즈니스 프로세스를 공유하여 협력해야 할 필요성

  • 일반 서비스와 이러한 서비스의 관리를 통합하려는 욕구

  • 시작, 종료, 유지 관리, 복구,로드 밸런싱 및 모니터링을 포함한 중앙 집중식 애플리케이션 관리를 제공하려는 욕구

  • 개방형 서비스 및 프로토콜을 사용하려는 욕구

  • 인프라의 제약없이 원하는대로 비즈니스 로직을 재배포하려는 욕구 이를 위해서는 대부분의 인프라 제품에서 광범위하게 지원되는 개방형 API 및 프로토콜을 사용해야합니다.

  • 협력하는 혼합 아키텍처 애플리케이션을 지원해야 할 필요성

  • 네트워크 및 서비스 인프라 결정을 애플리케이션 공간 밖으로 이동하여 시스템 관리자가 독점 프로토콜 또는 기능에 의존하는 애플리케이션에 의해 방해받지 않고 인프라 결정을 내릴 수 있도록하려는 욕구

  • 필요한 프로그래머 직원 기술의 다양성과 수준을 줄이고 프로젝트 내에서 고급 도구 구축 전문 지식의 필요성을 최소화하려는 열망

  • 객체 지향 전문 지식을 서버 영역으로 확장하여 활용하려는 욕구-따라서 새로운 객체 지향 서버 제품 및 객체 대 관계 브리지

미들웨어의 목표는 소프트웨어 인프라와 배포를 중앙 집중화하는 것입니다. 클라이언트 / 서버는 단일 부서 내의 통합 시대에서 시작되었습니다. 이제 조직은 일반적으로 한 조직에서 다른 조직으로도 부서 경계를 넘어 통합을 시도합니다. 부서와 파트너가 효율적이고 신속하게 상호 연결될 수있는 글로벌 네트워크 역할을 할 수있는 능력으로 기업을 유혹하는 인터넷은 이러한 통합에 대한 수요를 창출했습니다.

Java는 조직 경계를 넘어 데이터와 애플리케이션을 쉽게 상호 연결 하는 용어를 제공합니다 . 분산 된 글로벌 환경에서 파트너가 선택할 수있는 기술을 제어 할 수없는 경우 현명한 기업은 개방형 및 플랫폼 중립 표준을 선택합니다. 기업은 2 년 후에 누가 고객, 파트너 또는 자회사가 될지 예측할 수 없으므로 파트너와 공통 인프라를 계획하는 것이 항상 가능한 것은 아닙니다. 이 불확실한 상황에서 최선의 결정은 가능한 가장 보편적이고 적응 가능한 기술을 사용하는 것입니다.

Java를 사용하면 직원이 이해해야하는 프로그래밍 언어 및 플랫폼의 수를 줄일 수 있습니다. 왜? Java는 이제 인터넷 브라우저, 데이터베이스 내의 저장 프로 시저, 미들웨어 제품 내의 비즈니스 개체 및 클라이언트 측 애플리케이션과 같은 다양한 컨텍스트에 배포되기 때문입니다.

그러나 3 살이되었을 때 Java 기술은 여전히 ​​다소 미숙하며이 기사에서 논의한 제품도 마찬가지입니다. 반면에, 우리는 제품이 기반으로하는 기본 기술이 매우 빠르게 변하기 때문에 제품이 진정으로 성숙하지 못한 시대에있을 수 있습니다. 실제로 몇 년 동안 시장에 나와 최근에 중요한 새로운 기능이 나온 것으로 추정되는 성숙한 제품을 포함하여 내가 사용한 거의 모든 미들웨어 제품에서 중요한 문제를 발견했습니다. 요점은 공급 업체가 문제를 해결하기 위해 관리 할 때까지 새로운 기능이 추가되었다는 것입니다. 새로운 기능을 추가하는주기가 그 어느 때보 다 훨씬 짧아 졌으므로 제품은 다음 주요 기능 세트를 포함하기 전에 안정 될 시간이 충분하지 않습니다.이것은 우리가 익숙해 져야하는 것일 수 있으며, 우리가 선택한 제품의 강점과 약점을 배우는 것은 모든 애플리케이션 설계 및 프로토 타입주기에서 중요한 부분입니다.

미들웨어의 목표

EJB 미들웨어 구성 요소 표준은 다음과 같은 목표를 가지고 개발되었습니다.

  • 구성 요소 상호 운용성을 제공합니다. 다른 도구로 개발 된 엔터프라이즈 빈은 함께 작동합니다. 또한 다른 도구로 개발 된 Bean은 모든 EJB 환경에서 실행됩니다.

  • 저수준 API에 대한 액세스를 유지하면서 사용하기 쉬운 프로그래밍 모델을 제공합니다.

  • 개발, 배포 및 런타임을 포함한 수명주기 문제를 해결합니다.

  • EJB에 대한 지원을 제공하도록 기존 제품을 확장 할 수있는 기존 플랫폼과의 호환성을 제공합니다.

  • 다른 Java API와의 호환성을 유지하기 위해.

  • EJB와 비 Java 애플리케이션 간의 상호 운용성을 제공합니다.

  • CORBA와 호환됩니다.

따라서 EJB 표준의 초점은 Java 미들웨어에 대한 상호 운용성 표준을 작성하여 프로그래머가 분산 응용 프로그램을 개발할 때 발생하는 많은 어려운 문제를 처리 할 필요가 없도록 보호하는 것입니다. 이를 통해 소프트웨어 개발자는 정교한 자체 인프라 및 도구를 작성하는 대신 비즈니스 로직에 집중할 수 있습니다. 결과적으로 기업은 대부분의 교육 리소스를 비즈니스 프로세스의 직원 교육에 투입 할 수 있으며, 이는 일반적으로 가장 큰 보상을 제공합니다.

위 목록에 엔터프라이즈 급 Java 미들웨어에 대한 다음 추가 목표를 추가합니다. 이러한 제품 기능은 미들웨어 기반 환경을 성공적으로 실행하고 유지 관리하기 위해 장기적으로 필요합니다.

  • 보안을 손상 시키거나 혼란을 일으키지 않으면 서 분산 된 인프라에서 여러 사업부, 회사 및 고객의 상호 연결을 수용해야합니다.

  • 유연하면서도 신뢰할 수있는 액세스 제어 메커니즘을 통해 비즈니스 파트너 데이터가 의도 된 방식으로 만 의도 된 당사자에 의해서만 액세스되도록 보장해야합니다.

  • 시스템 관리자는 고유 한 절차를 이해하거나 특정 구성 요소에 적용 할 필요없이 일관된 방식으로 많은 수의 비즈니스 논리 구성 요소를 포함하는 분산 컴퓨팅 환경을 관리 할 수 ​​있어야합니다.

  • 시스템 관리자는 응용 프로그램에 영향을주지 않고 인프라 구성 요소를 선택하고 이러한 구성 요소를 조정 및 확장하고 모든 응용 프로그램의 성능 및 리소스 요구 사항을 측정하는 일관되고 일반적인 수단을 가질 수 있어야합니다.

  • 비즈니스 구성 요소가 둘 중 하나의 아키텍처에 영향을주지 않고 클라이언트와 서버간에 재배치 될 수 있어야합니다.

  • 서버 관리자에게 모든 구성 요소 및 데이터 원본에 대한 액세스 권한을 부여하지 않고도 특정 사용자가 새 구성 요소를 추가 할 수있는 보안 메커니즘을 제공해야합니다 (엑스트라 넷 및 파트너 관계 응용 프로그램에 중요하므로 부가 가치 기능을위한 좋은 기회입니다. )

Java 미들웨어 플랫폼의 구성 요소 및 기능

오늘날 가장 빠르게 성장하는 Java 미들웨어 범주는 아마도 애플리케이션 서버 일 것입니다. 그러나 존재하는 다양한 애플리케이션 서버 (및 기타 종류의 미들웨어 제품)를 실현하는 것이 필수적입니다. 오늘날 Java 미들웨어 제품 범주 간의 구별은 선이 아니라 방대한 미들웨어 연속체로 표현됩니다. 이제 내가 아는 모든 Java 미들웨어 제품 클래스를 포함하는 내 작업 비교를 기반으로 Java 미들웨어의 기능에 대해 논의 할 것입니다.

개체, 구성 요소 및 컨테이너 모델

응용 프로그램 구성 요소는 구성 요소가 환경과 통신하는 방법을 지정하는 일부 런타임 배포 모델을 준수해야합니다. (아마도) 설치, 시작, 중지 및 호출 방법 환경에 중요한 서비스에 액세스하는 방법. 인기있는 Java 중심 서버 구성 요소 런타임 및 컨테이너 모델에는 RMI, EJB, CORBA, DCOM, 서블릿, JSP (Java Server Pages) 및 Java 저장 프로 시저가 포함됩니다. 또한 구성 요소 모델은 Java, IDL, C ++ 및 기타 여러 언어를 포함한 다양한 기본 언어로 표현 될 수 있습니다.

다양한 구성 요소 모델과 겹치는 부분이 있습니다. 예를 들어, RMI는 객체 활성화 및 위치 지정을위한 매우 기본적인 기능을 갖춘 사소한 구성 요소 모델이며 주로 원격 호출 표준 인 반면 EJB는 RMI를 활용하고 RMI를 기본 객체 호출 모델로 지정합니다. EJB는 CORBA도 지원합니다. 실제로 이러한 모델 중 어느 것도 배타적 인 모델이 없으며 많은 Java 애플리케이션 서버가 위의 모델 대부분 또는 모두를 지원합니다.

많은 Java 미들웨어 서버는 단일 JVM (Java Virtual Machine) 내에서 여러 비즈니스 오브젝트 인스턴스 (현재 CORBA 세계에서 하위라고 함)를 실행합니다. Java 언어의 유형 안전성을 통해 단일 JVM 프로세스가 여러 클라이언트의 요청을 서비스하고 프로그램 데이터 구조와 클래스 로더를 사용하여 클라이언트 데이터를 별도로 유지할 수 있습니다. 하인이 자체 고유 메서드를 사용하지 않는 한, 한 하인이 충돌하는 경우 (JVM 자체에서 버그가 발생하지 않는 한) 다른 하인을 중단하거나 다른 클래스의 개인 데이터에 액세스 할 수 없습니다. . 적절하게 설계된 개체 서버는 개인 개체를 보호하고 잘못된 개체가 다른 개체에 속한 개체에 액세스하는 것을 방지합니다.

그러나 Java 클래스에서 정적으로 선언 된 데이터는 클라이언트가 동일한 클래스 로더를 사용하는 경우 동일한 JVM 내에서 클라이언트간에 공유 될 수 있으므로 별도의 JVM (또는 메모리를 사용하는 별도의 JVM에 해당하는 경우)을 지정하도록 규칙을 정의해야합니다. 파티셔닝 기술) 또는 별도의 클래스 로더가 클라이언트에 자체 정적 데이터 공간을 제공해야합니다. 이러한 규칙은 애플릿에 대해 지정되었지만 다른 실행 환경에는 지정되지 않았습니다. Sun의 Java Web Server는 모든 서블릿에 대해 단일 JVM을 사용하고 코드 기반이 다른 서블릿에 대해 별도의 클래스 이름 공간을 사용합니다. EJB는 최종이 아닌 정적 데이터를 금지하여 문제를 우회합니다.

개체를 사용하지 않을 때 비활성화하거나 비활성화하면 성능이 향상되어 데이터베이스 연결과 같은 리소스를 확보 할 수 있습니다. 이러한 이유로 많은 서버가 적절하게 개체를 비활성화하고 다시 활성화합니다. 마찬가지로 일부 제품은 자주 생성되는 개체를 풀 또는 캐시에 초기화 된 상태로 유지하고 즉시 사용할 수 있도록 준비합니다. 개체 컨테이너는 패시베이션의 영향을받는 풀링 된 리소스뿐 아니라 패시베이션 및 재 활성화를 관리해야합니다.

EJB 호환성 (버전)

EJB 모델은 이미 보편적으로 지원되고 있습니다. 거의 모든 미들웨어 공급 업체가이를 지원하겠다고 약속했으며 많은 업체가 이미 지원하고 있습니다. 또한 OMG (Object Management Group)는 제안 된 CORBA 구성 요소 사양의 일부로 EJB에 대한 매핑을 통합했습니다 . 고독하고 확고부동 한 Microsoft조차도 결국 DCOM을위한 EJB 컨테이너를 양보하고 제공하지 않을 것이라고 상상하기는 어렵습니다.

서로 다른 EJB 호환 미들웨어는 동일한 애플리케이션 구성 요소를 배포하고 운영 할 수 있지만 (이러한 구성 요소가 표준 필수 EJB 기능 만 사용하는 한) EJB 호환 서버 간에는 여전히 많은 차이가 있습니다. 우선 EJB 사양 자체가 진화하고 있습니다. 따라서 Java 미들웨어 제품을 평가할 때 중요한 질문은 다음과 같습니다. 서버가 최신 버전의 EJB를 지원합니까, 아니면 이전 버전 만 지원합니까? 또 다른 핵심 질문은 다음과 같습니다. 제품이 EJB 중심입니까, 아니면 EJB 지원이 제품의 부가 가치 기능에만 포함되어 있습니까 (따라서 EJB 서비스 또는 API를 사용할 때 사용할 수 없음)? 마지막으로 어떤 선택적 EJB 기능이 포함됩니까 (예 : 엔티티 Bean 및 컨테이너 관리 지속성)?