WEBLOGIC SERVER와 SPRING 통합

by Andy Piper, Rod Johnson, Chris Wall and Nick Tran
2005/09/28

개요

BEA WebLogic Server 9.0은 Sun Microsystems의 J2EE 1.4 플랫폼을 구현하는 선도적인 솔루션입니다. 그러나 WebLogic Server의 핵심적 가치는 관리 기능 향상, 사용 편이성, 고가용성, 확장성, 신뢰성 및 성능 등 J2EE 사양에서 다루지 않는 영역에 있습니다. WebLogic Server의 가치는 특정 프로그래밍 모델에만 한정되지 않기 때문에 새로 등장하는 비J2EE 프로그래밍 모델에서도 자연스럽게 사용할 수 있습니다. 최근 부상하는 모델 중 가장 흥미로운 모델은 Spring Framework가 주도적으로 구현하는 IoC(Inversion of Control) 기반의 모델입니다. 이 문서에서는 Spring Framework 및 WebLogic Server의 기능을 소개하고 이 두 기술의 통합에 대해 설명합니다. 또한 이 두 기술의 통합으로 인하여 더 큰 효과를 얻을 수 있음을 알게 될 것입니다.

본 문서의 구성

처음 두 단원에서는 Spring 및 WebLogic Server의 개요 및 각 기능에 대해 살펴봅니다. Spring Framework에 대해 잘 알고 있다면 첫 번째 단원을 건너뛰어도 되고, WebLogic Server에 대해 잘 알고 있다면 두 번째 단원을 건너뛰어도 됩니다. 이 문서는 무엇보다도 두 기술의 통합에 대해 다루므로 나머지 부분에서는 이 주제에 대해 중점적으로 설명합니다. 약간의 배경 설명을 곁들이기 위해 먼저 WebLogic Server에 함께 제공되는 샘플 애플리케이션인 MedRec을 원래의 J2EE 형식으로 살펴본 다음 Spring Framework를 사용하여 다시 살펴봅니다. 그런 다음 특정 통합 문제를 중심으로 자세히 살펴봅니다. WebLogic Server 위에서 Spring 애플리케이션을 개발하려 한다면 분명 세부 정보 수준이 유용할 것입니다. 먼저 어떤 내용이 들어있는지 알아보고 싶다면 제목을 읽어보고 내용은 나중에 확인할 수 있습니다. 마지막으로 구상 중인 향후 개발 방향에 대해 요약하고 그 일부를 살펴봅니다.

Spring 소개

이 단원에서는 Spring Framework의 기능을 간단하게 설명합니다.

Rod Johnson이 저술한 Expert One-on-One J2EE Design and Development(Wrox, 2002)에서 설명한 바와 같이 Spring은 코드에 기반을 둔 레이어 구조의 Java/J2EE 애플리케이션 프레임워크입니다. Spring이 존재하는 이유는 J2EE가 사용하기 더 편리하고 플랫폼의 성능을 저하시키지 않고도 J2EE를 쉽게 개발할 수 있다는 믿음에서 비롯합니다.

Spring을 사용하면 신속하게 J2EE를 개발할 수 있고 POJO를 사용하여 J2EE 애플리케이션을 개발할 수 있습니다.

Spring을 사용하여 개발 경험 향상

근본적으로 Spring은 구성하기 편리한 XML 기반의 IoC(Inversion of Control) 컨테이너를 제공합니다. IoC는 "전화하지 마세요. 우리가 전화하겠습니다."라는 소위 "할리우드" 원칙을 기반으로 합니다. 이러한 스키마에서 애플리케이션의 Java 객체 간의 관계는 사용자가 직접 프로그래밍하는 것이 아니라 컨테이너에서 삽입됩니다. 이러한 삽입에는 컨테이너가 constructor 메서드 또는 그 mutator 메서드를 통해 생성된 Java 객체에 정보를 삽입하는지 여부에 따라 구성자(constructor) 삽입 및 설정자(setter) 삽입 두 가지 형태가 있습니다.

Spring에서 삽입된 속성(또는 다른 빈에 대한 참조)은 XML 파일을 통해 구성되므로 구성이 거의 전체적으로 평범합니다. 다시 말해 트랜잭션 및 보안과 같은 속성을 자연스럽게 추가할 수 있는 AOP 프레임워크와 결합되어 개발자가 J2EE 개발 또는 구성의 복잡성에 얽매이지 않고 비즈니스 문제의 해결책을 만드는 데 집중할 수 있음을 의미합니다. 컨테이너가 비공격적이기 때문에 비즈니스 코드가 벤더별(여기서는 Spring 포함) 결과물로 인해 오염되지 않는다는 점에서 마음을 놓을 수도 있습니다.

Spring 애플리케이션 컴포넌트

이미 말한 바와 같이 Spring은 중앙 집중화되고 자동화된 구성을 제공하고 애플리케이션 객체를 작성할 수 있는 간단한 컨테이너를 제공합니다. 이 컨테이너는 비공격적이고, IoC를 통해 느슨하게 연결된 컴포넌트(POJO) 세트로부터 복잡한 시스템을 지속적이고 투명한 방식으로 조립할 수 있습니다. 컨테이너는 민첩성 및 활용성을 제공하고, 소프트웨어 컴포넌트를 먼저 격리된 환경에서 개발 및 테스트한 다음 모든 환경(J2SE 또는 J2EE)에 배포하기 위해 확장할 수 있도록 함으로써 애플리케이션의 테스트 용이성 및 확장성을 향상시킵니다. 또한 Spring은 다음과 같이 개발자 친화적인 기능을 다수 제공합니다.

• 트랜잭션 관리를 위한 일반 추상화 레이어, 이러한 레이어를 통해 연결 가능한 트랜잭션 관리자를 고려해 볼 수 있고 낮은 수준의 문제를 다루지 않고도 트랜잭션의 경계 설정을 수행하기가 쉬워졌습니다. JTA 및 단일 JDBC DataSource에 대한 일반적인 전략이 포함되어 있습니다. 일반 JTA 또는 EJB CMT와 달리 Spring의 트랜잭션 지원은 J2EE 환경에만 국한되어 있지 않습니다.

• JDBC 추상화 레이어, 이 레이어는 더 이상 SQLException에서 벤더 코드를 끌어내지 않고 의미 있는 예외 계층 구조를 제공하고, 오류 처리를 단순화하며 작성해야 하는 코드 분량이 대폭 줄어듭니다. JDBC를 다시 사용하기 위해 또 다른 finally 블록을 작성할 필요가 없습니다. JDBC 지향적 예외는 Spring의 일반적인 DAO 예외 지배 구조를 따릅니다.

• 리소스 홀더, DAO 구현 지원 및 트랜잭션 전략 관점에서 업계 선도적인 객체-관계형 매핑 솔루션과 통합 , 수많은 IoC의 편리한 기능으로 최상의 지원을 제공하고 일반적인 O-R 매핑 통합 문제를 해결합니다. 이러한 모든 기능은 Spring의 일반적인 트랜잭션 및 DAO 예외 지배 구조를 따릅니다.

• Spring 구성 관리에 완전히 통합된 AOP 기능, Spring에서 관리하는 모든 객체를 AOP할 수 있어서 선언적 트랜잭션 관리 같은 기능을 추가할 수 있습니다. Spring에서는 EJB 없이(심지어 JTA 없이도) 선언적 트랜잭션 관리를 가질 수 있습니다.

• 핵심적인 Spring 기능을 기반으로 구축되어 유연한 MVC 웹 애플리케이션 프레임워크 , 이 프레임워크는 전략 인터페이스를 통해 편리하게 구성할 수 있으며 JSP, Velocity, Tiles, iText 및 POI 같은 다중 뷰 기술을 수용합니다. Spring 중간 계층은 struts, WebWork 또는 Tapestry 같은 다른 웹 MVC 프레임워크를 기반으로 구축된 웹 계층과 쉽게 결합될 수 있습니다.

Spring의 모든 기능은 모든 J2EE 서버에서 사용할 수 있으며 관리되지 않는 환경에서도 거의 대부분의 기능을 사용할 수 있습니다. Spring의 주요 관심은 재사용 가능한 비즈니스와 특정 J2EE 서비스에 국한되지 않은 데이터 액세스 객체를 고려하는 문제입니다. 이러한 객체는 J2EE 환경(웹 또는 EJB), 독립 실행형 애플리케이션 및 테스트 환경에서 어떠한 충돌도 없이 재사용될 수 있습니다.

Spring의 레이어 구조 아키텍처는 상당한 유연성을 제공합니다. 모든 기능이 낮은 수준에 구축됩니다. 그러므로 예를 들어 MVC 프레임워크 또는 AOP 지원을 사용하지 않고도 JavaBeans 구성 관리를 사용할 수 있습니다. 그러나 웹 MVC 프레임워크 또는 AOP 지원을 사용하는 경우 모든 기능이 구성 프레임워크에 구축되므로 이에 관한 지식을 즉시 적용할 수 있습니다.

BEA WebLogic Server 소개

이 단원에서는 프로그래밍 모델 보다는 제공되는 기저의 인프라스트럭처를 중심으로 BEA WebLogic Server의 기능에 대해 간단히 설명합니다.

WebLogic Server는 기업에서 바로 사용할 수 있는 확장 가능한 J2EE 애플리케이션 서버입니다. WebLogic Server 인프라스트럭처는 여러 유형의 분산 애플리케이션의 배포를 지원하므로 모든 종류의 애플리케이션을 구축하기에 이상적인 기반입니다.

Sun Microsystems J2EE 1.4 사양을 구현하는 WebLogic Server는 데이터베이스, 메시징 서비스 및 외부 엔터프라이즈 시스템에 연결 등 광범위한 서비스에 액세스할 수 있는 분산 Java 애플리케이션을 구축할 수 있는 표준 API 세트를 제공합니다. 최종 사용자 클라이언트는 웹 브라우저 클라이언트 또는 Java 클라이언트를 사용하여 이러한 애플리케이션에 액세스합니다. J2EE에 대해서는 잘 알려져 있기 때문에 여기서는 더 이상 설명하지 않겠습니다. 자세한 내용은 WebLogic Server 설명서에서 프로그래밍 모델을 참조하십시오.

기업은 WebLogic Server를 통해 J2EE 구현 이외에도 강력하고 안전한 고가용성의 확장 가능한 환경에 미션 크리티컬한 애플리케이션을 배포할 수 있습니다. 이러한 기능을 사용하여 기업은 로드를 분산하기 위해 WebLogic Server 인스턴스의 클러스터를 구성할 수 있고 하드웨어 오류나 다른 오류 발생 시 추가 기능을 제공할 수 있습니다. 시스템 관리자는 새로운 진단 도구를 사용하여 배포된 애플리케이션의 성능과 WebLogic Server 환경 자체를 모니터링하고 조정할 수 있습니다. 또한 작업자의 개입 없이 자동으로 애플리케이션 처리량을 모니터링하고 조정하도록 WebLogic Server를 구성할 수도 있습니다. 확대된 보안 기능은 서비스에 대한 액세스를 보호하고 엔터프라이즈 데이터를 안전하게 유지하며 악의적인 공격으로부터 보호해줍니다.

WebLogic Server를 사용하여 서비스 품질 향상

다른 BEA 제품과 마찬가지로 눈에 보이는 WebLogic Server의 기능은 빙산의 일각에 불과합니다. 특히, WebLogic Server는 고가용성의 확장 가능한 애플리케이션의 배포를 지원하는 수많은 기능과 도구를 제공합니다.

• WebLogic Server 클러스터는 WebLogic Server의 다중 인스턴스에서 작업 부하를 분산시켜 애플리케이션에 확장성 및 신뢰성을 제공합니다. 수신되는 요청은 처리할 작업 분량을 바탕으로 클러스터의 WebLogic Server 인스턴스로 라우팅될 수 있습니다. 하드웨어 오류나 다른 오류 발생 시 세션 상태를 다른 클러스터 노드에서 사용할 수 있어서 오류가 발생한 노드의 작업을 계속할 수 있습니다. 또한 오류 발생 시 해당 서비스를 다른 노드로 마이그레이션하는 옵션이 포함된 단일 시스템에서 해당 서비스를 호스트할 수 있도록 클러스터를 구현할 수 있습니다.

• 클러스터 내의 서버에서 HTTP 세션 상태를 복제하는 것 이외에도 WebLogic Server는 여러 클러스터에서 HTTP 세션 상태를 복제할 수 있습니다. 그러므로 다양한 지역, 파워 그리드 및 인터넷 서비스 공급자의 가용성 및 무정지 기능이 확대됩니다.

• Work Managers는 사용자가 정의한 규칙을 바탕으로 작업의 우선 순위를 정하고 실제 런타임 성능 통계를 모니터링합니다. 그런 다음 이 정보를 사용하여 애플리케이션의 성능을 최적화합니다. Work Manager는 WebLogic Server 도메인 또는 특정 애플리케이션 컴포넌트에 전체적으로 적용될 수 있습니다.

• 오버로드 방지 기능은WebLogic Server에 오버로드 상태를 피하거나 감지, 및 복구할 수 있는 기능을 제공합니다.

• 네트워크 채널은 네트워크 트래픽을 트래픽 유형을 바탕으로 한 채널로 분리시켜 네트워크 리소스를 효율적으로 사용할 수 있도록 합니다.

• WebLogic Server 영구 저장소는 지속성이 요구되는 WebLogic Server 하위 시스템 및 서비스를 위해 내장된 고성능 저장소 솔루션입니다. 예를 들어, 영구적인 JMS 메시지를 저장하거나 저장 후 전달(store-and-forward) 기능을 사용하여 전달된 메시지를 임시로 저장할 수 있습니다. 이러한 영구 저장소는 파일 기반 저장 또는 JDBC 사용 데이터베이스의 지속성을 지원합니다.

• 서비스 저장 후 전달(Store-and-forward services) 기능을 통해 WebLogic Server는 WebLogic Server 인스턴스에 분산되어 있는 애플리케이션 간에 메시지를 신뢰성 있게 전달할 수 있습니다. 메시지가 전달되는 순간에 네트워크 문제나 시스템 오류로 인해 메시지 대상을 사용할 수 없으면 해당 메시지를 로컬 서버 인스턴스에 저장한 다음 대상을 사용할 수 있게 되면 바로 원격 대상으로 메시지를 전달합니다.

• 기업용 배포 도구는 애플리케이션 개발 단계에서 운영 환경으로 편리하게 배포하고 마이그레이션할 수 있도록 지원합니다.

• 제작 재배포 기능을 통해 기업은 이전 버전 기반으로 진행 중인 작업을 중단하지 않고도 새로운 버전의 애플리케이션을 배포할 수 있습니다.

이제 이러한 두 시스템 간 시너지 효과를 살펴보겠습니다.

J2EE 및 Spring에서 애플리케이션 개발

J2EE와 Spring의 서로 다른 개발 접근법을 비교 및 대조해 보기 위해 MedRec 샘플 애플리케이션을 가져와 Spring Framework를 사용하여 다시 작성해보았습니다. 다음 단원에서는 MedRec의 일반적인 아키텍처에 대해 간단히 소개하고 이를 J2EE 형태로 먼저 살펴본 다음 다시 Spring 형태로 살펴보겠습니다.

Medical Records 애플리케이션

Avitek Medical Records(또는 MedRec)는 J2EE 플랫폼의 모든 측면을 명백하게 보여주는 WebLogic Server 샘플 애플리케이션입니다. MedRec은 모든 수준의 J2EE 개발자를 위한 교육용 도구로 설계되었습니다. 이 애플리케이션에서는 각 J2EE 컴포넌트의 사용을 소개하고 컴포넌트 상호 작용 및 클라이언트 개발을 위한 설계 패턴을 보여 줍니다. 또한 MedRec은 WebLogic Server에서 애플리케이션 개발 및 배포에 대한 모범 사례를 보여 줍니다.

MedRec의 실제 개념은 환자, 의사 및 관리자가 서로 다른 클라이언트를 사용하여 환자 데이터를 관리할 수 있는 프레임워크입니다. 환자의 경우, MedRec은 사용자가 자신의 의료 기록 내역을 보고 프로파일을 유지 관리할 수 있는 웹 기반 애플리케이션을 제공합니다. 관리자의 경우, MedRec은 수신되는 등록, 의료 기록 업로드 및 일반 애플리케이션 모니터링을 관리할 수 있는 웹 기반 애플리케이션을 제공합니다. 또한 MedRec은 독립 의료 기관과 연결하는 리소스를 가지고 있습니다. 이러한 커뮤니케이션을 입증하기 위해 MedRec은 MedRec 시스템에 데이터를 요청 및 제공하는 의사 애플리케이션으로 구성되어 있습니다.

J2EE에서의 MedRec-아키텍처 개요

J2EE 및 WebLogic Server 버전의 MedRec은 클라이언트, 서버 및 데이터 저장소가 서로 독립적인 일반적인 3계층 아키텍처 모델을 기반으로 설계 및 구현되었습니다.

• 프레젠테이션 계층: 이 계층은 모든 사용자 상호 작용을 담당합니다. 클라이언트 계층이라고도 합니다.

• 서비스 계층: 이 계층은 애플리케이션의 비즈니스 로직을 캡슐화하는 중간 계층입니다. 서비스 계층은 데이터 저장소를 비롯한 다양한 백엔드 시스템과 연결하는 한편, 이기종 클라이언트의 요청을 처리합니다. 이 계층을 서버 계층이라고도 합니다.

• EIS(Enterprise Information System) 계층: 이 계층은 레거시 애플리케이션 및 데이터베이스 같이 데이터를 제공 및/또는 저장하는 시스템을 나타냅니다. EIS 계층을 데이터 저장소라고 하기도 합니다.

MedRec의 환자 애플리케이션과 관리 애플리케이션의 경우, 각 사용자에게 서비스를 제공하기 위해 웹 애플리케이션(webapps)을 개발했습니다. webapps는 MVC(Model-View-Controller) 패턴을 따르는데, 여기서 Java Server 페이지는 사용자에 대한 View를 렌더링하고, Model은 사용자에게 제공되거나 사용자에게서 캡처한 데이터를 캡슐화하며, Controller는 서비스 계층과의 연결은 물론 이러한 컴포넌트의 상호 작용을 관리하는 메커니즘입니다. MedRec은 이러한 패턴을 수행하기 위해 Jakarta struts를 사용합니다.

서비스 계층은 요청하는 클라이언트에 서비스를 제공하고 백엔드 애플리케이션 및 리소스와의 상호 작용을 관리합니다. MedRec의 서비스 계층은 비즈니스 로직 및 비즈니스 데이터를 캡슐화하기 위해 Session Facade 패턴을 사용합니다. Session Facades는 분산 서비스에 인터페이스를 제공하여 애플리케이션의 복잡성을 단순화합니다. MedRec에서 Session Facades의 주요 역할은 데이터 처리량을 제공하는 것입니다. J2EE 및 WebLogic Server 버전의 MedRec에서 Sessions Facades는 비상태유지 세션 Enterprise JavaBeans로 개발되었으며 데이터는 엔티티 Enterprise JavaBeans에서 관리합니다.

MedRec은 외부 엔티티와 연결하기 위해 웹 서비스를 통해 애플리케이션 기능을 제공하므로 일련의 공개 표준을 사용하는 각기 다른 시스템 간의 동적 상호 작용을 구현합니다. 또한 웹 서비스를 통해 서비스를 제공함으로써 독립 의료 기관에 데이터를 제공하고 해당 기관으로부터 데이터를 받을 수 있어 중앙에서 의료 기록을 관리하는 주요 목적을 달성할 수 있습니다.

그림 1은 J2EE 및 WebLogic Server 버전 MedRec의 수준 높은 아키텍처 다이어그램을 보여 줍니다.

그림 1: J2EE 버전 MedRec의 아키텍처 다이어그램

Spring 경험하기-Medrec 재구성

Spring에서 WebLogic Server의 엔터프라이즈 기능을 활용할 수 있도록 핵심 J2EE 컴포넌트를 Spring 컴포넌트로 대체하여 MedRec을 재구성했습니다. Spring 기반 버전의 MedRec(MedRec-Spring)을 사용하여 MedRec의 원래 버전과 동일한 기능을 복제했습니다.

MedRec-Spring에 가장 특이할만하게 추가된 것은 Spring의 IoC를 도입한 것입니다. IoC는 구성된 컴포넌트에 의존성을 삽입하는 컨테이너를 통해 적용되는 강력한 원칙입니다. IoC는 애플리케이션 구성에서 코드를 분리시킵니다. 예를 들어, 객체는 의존성과 관련이 없기 때문에 객체의 책임에 초점을 맞출 수 있습니다. MedRec-Spring의 경우 런타임에 DataSources, JMS 서비스, MBean 연결 및 피어 서비스 같은 엔터프라이즈 리소스를 MedRec-Spring의 객체에 제공합니다. 또한 리소스 구성을 마이그레이션하고 컴파일된 코드 외부를 참조하여 애플리케이션은 개발 리소스에서 운영 리소스 및 그 사이 환경으로의 이동을 보다 쉽게 관리할 수 있습니다.

IoC를 제대로 적용하려면 애플리케이션 코드가 더 엄격한 Java 프로그래밍 원칙 특히 인터페이스에 대한 코딩을 따라야 한다는 사실을 깨달았습니다. 의존성이 낮아지고 구현 변경이 고립되기 때문에 다른 어떤 것보다도 인터페이스가 협업을 증대시킵니다. IoC 관점에서 볼 때 인터페이스는 의존성 삽입의 연결 가능한 특징을 고려합니다. IoC의 이점을 활용하기 위해 인터페이스에 대해 비즈니스 객체를 코딩할 수 있도록 MedRec-Spring을 리팩토링했습니다.

MedRec-Spring에서 비상태유지 세션 EJB는 POJO(Plain Old Java Objects)로 대체됩니다. 비상태유지 세션 EJB의 장점은 원격 지원 기능과 트랜잭션 관리입니다. MedRec-Spring은 Spring의 HTTP Invoker 아키텍처를 통해 서비스 빈을 제공하여 원격 지원 요구 사항을 해결했습니다. 트랜잭션 관리는 Spring의 트랜잭션 추상화 레이어에서 제공됩니다. Spring 트랜잭션 관리자가 WebLogic Server의 JTA 트랜잭션 관리자에게 책임을 위임하도록 구성되어 있기 때문에 트랜잭션 관리는 원래 MedRec의 트랜잭션 관리를 똑같이 재연합니다.

MedRec-Spring에는 원래 MedRec의 메시징 기능이 거의 포함되어 있습니다. Spring의 JMS 패키지를 사용하여 연결 팩토리 및 대상 조회 같은 평범한 작업을 단순화 했습니다. Spring은 프로그래밍 방식으로 대기열에서 핸들을 얻지 않고 메시징 대상을 나타내는 객체를 제공합니다. 모든 Spring 빈과 마찬가지로 JNDI 이름, 연결 팩토리 결합 등 이러한 객체가 나타내는 내용은 컴파일된 코드 외부에 구성됩니다.

MedRec-Spring에는 애플리케이션 관리 기능이 포함되어 있습니다. 이러한 기능은 자체 런타임 도메인 뿐만 아니라 WebLogic Server의 도메인 구성과도 상호 작용합니다. MedRec-Spring은 반드시 WebLogic Server의 MBean Servers를 따라 실행해야 하며, Spring은 MBean Server의 접근성을 단순화하는 연결 관리를 제공합니다.

마지막으로 MedRec-Spring은 웹 서비스를 사용하여 서비스를 내보냅니다. Spring은 웹 서비스에 대한 프록시를 생성하는 JAX-RPC 팩토리를 제공합니다. 다른 Spring 빈과 마찬가지로 이 팩토리 빈은 컴파일된 코드 외부에 구성되어 애플리케이션이 더욱 유연해집니다.

그림 2는 Spring 기반 MedRec 버전의 수준 높은 아키텍처 다이어그램을 보여 줍니다.

그림 2: Spring 기반 MedRec 버전의 아키텍처 다이어그램

WebLogic Server를 사용하는 Spring 모범 사례

J2EE 환경 및 Spring 환경에서 MedRec 아키텍처를 비교해보았으므로 이제는 MedRec-Spring 애플리케이션 구현 시 알아야 할 중요한 내용에 대해 살펴보겠습니다.

• 느슨한 초기화 사용. IoC 컨테이너를 구현하기 위해 Spring은 애플리케이션 컨텍스트 파일을 로드하고 구성된 각 빈의 인스턴스를 생성 및 캐시합니다. Spring 빈에서 참조하는 각 리소스를 인스턴스화 또는 조회 시 사용할 수 있어야 한다는 사실을 이해하는 것이 중요합니다. 예를 들어, Spring의 JMX 지원은 WebLogic Server의 MBean 서버에 대한 연결을 제공합니다. 배포 시 모든 MBean 서버가 활성화되지 않기 때문에 사용자는 리소스를 배포하는 경우 시작할 때 Spring의 느슨한 초기화 및 조회 서비스를 사용해야 합니다.

• 기능을 기반으로 Spring 구성 분리. 이러한 기능으로 애플리케이션 컴포넌트는 자신의 작업 책임에 속한 컨텍스트만 로드할 수 있습니다. 또한 실무에서 테스터가 하나의 애플리케이션 컨텍스트(예: DataSource 구성)를 테스트 환경에 맞는 컨텍스트로 대체하여 애플리케이션의 동작을 변경할 수 있습니다.

• JndiObjectFactoryBean을 통해 JDBC DataSource 연결 풀링 캡슐화. 데이터베이스 상호 작용이 요구되는 빈이 WebLogic Server의 DataSource 풀링 기능을 사용하기 위해 이러한 빈을 참조할 수 있습니다.

• 세션 및 메시지 드리븐 Enterprise JavaBeans에 Spring의 org.springframework.ejb.support 사용. Spring의 org.springframework.ejb.support는 EJB(Enterprise JavaBeans)가 확장할 수 있는 추상적인 클래스를 제공합니다. 이러한 추상적인 EJB 클래스는 EJB 라이프사이클 메서드에 대한 표준 구현을 포함시켜 개발을 도와줍니다. 이러한 클래스가 다양한 EJB 및 클라이언트에서 컨텍스트 공유 및 EJB 초기화 시 복제 및 오버헤드 감소 등 Spring의 애플리케이션 컨텍스트를 로드하기 위한 메커니즘을 제공하는 사실이 더 중요합니다.

• 핫 배포 및 WebLogic Server의 분할 개발 디렉토리 환경의 활용. 이러한 기능은 통합 테스트 시 Spring 개발 경험을 상당히 향상시킵니다. 핫 배포를 통해 애플리케이션에서 서버를 다시 시작하지 않고 다시 로드할 수 있습니다. 분할 개발 디렉토리 환경에서는 불필요한 파일 복사를 최소화하여 개발 및 배포를 앞당길 수 있습니다. 분할 개발 디렉토리 Ant 작업은 배포 가능한 보관 파일 또는 파열된 보관 디렉토리를 먼저 생성하지 않고 애플리케이션을 신속하게 재컴파일 및 재배포할 수 있도록 도와줍니다.

• 애플리케이션 라이브러리, 옵션 익스텐션, 또는 서버 익스텐션과 같은 Spring 라이브러리 패키지화. 이러한 기능으로 일부 Spring 애플리케이션은 Spring Framework를 공유하고 애플리케이션 점유 공간을 줄일 수 있습니다. 이로써 메모리 사용이 줄어들 뿐 아니라 배포 시간도 단축됩니다.

WebLogic Server 기반의 Spring 키트

WebLogic Server에 배포된 Spring 애플리케이션을 최대한 활용할 수 있도록 Spring 1.2.5, Spring 기반의 MedRec 애플리케이션 및 다른 많은 제품들이 포함된 BEA 인증 배포를 구축했습니다. 이 키트는 BEA의 배포 웹 사이트에서 무료로 다운로드할 수 있습니다.

Enterprise Spring

Spring Framework의 비공격적 IoC 개발 모델은 J2EE 애플리케이션 서버에서 사용할 수 있는 기능 세트에 의존하며 이를 보완하기 위해 설계되었습니다. 까다로운 제작 환경에서 기저 애플리케이션 서버 인프라스트럭처에 의한 양질의 서비스는 Spring 애플리케이션의 신뢰성, 가용성 및 성능을 지속적으로 제공하기 위해 항상 중요합니다. WebLogic Server 9.0은 Spring 애플리케이션의 모든 측면을 향상시킬 수 있는 엔터프라이즈급 기능을 제공합니다. 이 단원에서는 이러한 일부 기능을 자세하게 소개하고 Spring 애플리케이션에서 이러한 기능을 활용하는 방법에 대해 설명합니다.

클러스터 관리 및 배포

WebLogic Server 클러스터는 확장성 및 신뢰성을 높이기 위해 동시에 실행되고 연동하는 여러 개의 WebLogic Server 서버 인스턴스로 구성됩니다. 클러스터는 클라이언트에게 단일 WebLogic Server 인스턴스로 표시됩니다. 클러스터를 구성하는 서버 인스턴스는 동일한 시스템에서 실행되거나 서로 다른 시스템에 있을 수 있습니다. 기존 시스템의 클러스터에 추가 서버 인스턴스를 추가하여 클러스터 기능을 증대하거나 늘어나는 서버 인스턴스를 호스트하기 위해 클러스터에 시스템을 추가할 수 있습니다. WebLogic Server 클러스터는 Spring 애플리케이션을 위한 엔터프라이즈급 배포 플랫폼을 제공합니다. 다른 기술도 이와 유사한 기능을 지원하지만 어느 것도 WebLogic Server에서 제공하는 풍부함과 사용 편이성을 제공하지는 못합니다. WebLogic Server 클러스터의 구성 및 관리에 대한 자세한 설명은 클러스터 구성 및 애플리케이션 배포 이해(Understanding Cluster Configuration and Application Deployment)를 참조하십시오.

일반적으로 Spring 애플리케이션은 webapps로 패키지되어 있으며 이 경우 WebLogic Server 클러스터링을 사용하기 위해 애플리케이션을 변경할 필요가 없습니다. 단지 클러스터의 서버에 애플리케이션을 배포하고 향상된 확장성 및 가용성 이점을 활용하면 됩니다.

Spring 세션 복제

Spring 웹 애플리케이션은 습관적으로 주문 ID 및 사용자 정보 같은 정보를 HTTP 세션에 저장합니다. 클러스터 내의 서블릿 및 JSP에 자동 복제 및 장애 조치를 지원하기 위해 WebLogic Server는 몇 가지 메커니즘을 지원함으로써 HTTP 세션 상태를 유지합니다. 애플리케이션에 적절한 weblogic.xml 배포 설명자를 제공하기만 하면 Spring 웹 애플리케이션에서 이러한 기능을 자연스럽게 사용할 수 있습니다. WebLogic Server 9.0에서 사용할 수 있는 다양한 유형의 세션 지속성 구성에 대해 자세히 알아보십시오.

클러스터된 Spring 원격 지원

Spring은 강력한 원격 지원을 제공하므로 지속적인 POJO 기반의 프로그래밍 모델을 계속 활용하면서도 원격 서비스를 간편하게 내보내고 소비할 수 있습니다. Vanilla Spring은 해당 Spring 빈의 단일 RMI 인터페이스를 통해 POJO 호출 프록시를 지원합니다. 그러나 이러한 지원은 JRMP(Sun의 RMI 구현)로 제한되거나 RmiProxyFactoryBean을 사용하는 특정 원격 인터페이스 사용으로 제한됩니다. WebLogic Server 9.0 기반의 Spring 1.2.5의 인증을 사용하여, RMI-IIOP 및 T3을 비롯한 모든 J2EE RMI 구현에서 POJO 프록시를 지원하도록 JndiRmiProxyFactoryBean 및 관련된 서비스 내보내기를 확장했습니다. 이러한 지원 기능에 프록시 RMI 인터페이스에서 클러스터링할 수 있는 WebLogic RMI 배포 설명자를 포함시켜 WebLogic Server 클러스터에서 POJO 호출을 로드 밸런싱할 수 있습니다. 이렇게 지원되는 클라이언트 구성은 다음과 같습니다.

<bean id="proProxy"
  class="org.springframework.remoting.rmi.JndiRmiProxyFactoryBean">
   <property name="jndiName" value="t3://${serverName}:${rmiPort}/order"/>
   </property>
   <property name="jndiEnvironment">
      <props>
         <prop key="java.naming.factory.url.pkgs"> 
		    weblogic.jndi.factories
         </prop>
      </props>
   </property>
   <property name="serviceInterface"
	 value="org.springframework.samples.jpetstore.domain.logic.OrderService"/>
</bean>

서비스 내보내기는 다음과 같습니다.

<bean id="order-pro"   class="org.springframework.remoting.rmi.JndiRmiServiceExporter">
   <property name="service" ref="petStore"/>
   <property name="serviceInterface"
     value="org.springframework.samples.jpetstore.domain.logic.OrderService"/>
   <property name="jndiName" value="order"/>
</bean>

클러스터된 설명자는 자동으로 포함되고 단지 해당 클러스터를 구성하고 모든 클러스터 멤버에 Spring 애플리케이션을 배포해야 합니다. 장애 조치 지원에 대해 자세히 알아보십시오.

Spring 컴포넌트에 대한 콘솔 지원

Spring on WebLogic Server 키트에는 Spring 빈, 속성 및 애플리케이션에 정의된 동작을 표시하는 WebLogic Server 콘솔 익스텐션이 포함되어 있습니다. 이 콘솔은 WebLogic 콘솔 익스텐션 포털 프레임워크에 구축되어 있어서 서버 또는 콘솔 코드를 수정하지 않고 WebLogic Administration Console의 외양과 느낌, 기능 및 레이아웃을 변환할 수 있습니다. 콘솔 익스텐션을 yourdomain/console-ext 디렉토리로 복사하면 콘솔 익스텐션이 배포되고 서버가 다시 시작됩니다. 콘솔 익스텐션 배포에 관한 자세한 내용은 WebLogic Server 기반의 Spring 키트를 참조하십시오.

콘솔 익스텐션은 대부분의 Spring 빈의 경우와 마찬가지로 Mbeans가 아닌 Spring 빈에 대해 (JMX) 관리 인터페이스를 자동으로 만들어 작동하고 applicationContext.xml에 MBeanExporter를 구성하고 어셈블러를 통해 제공될 빈을 지정하면 동작이 완료됩니다. 이러한 기능은 Spring과 WebLogic Server가 완벽하고 자연스럽게 연동됨을 보여주는 좋은 예입니다. Spring 애플리케이션을 JMX에서 사용하려면 애플리케이션 컨텍스트 배포 설명자를 변경해야 하고 콘솔을 Spring에서 사용하려면 기존 도메인에 간단한 jar를 배포해야 합니다.

웹 서비스 사용 가능

Spring의 원격 지원 기능의 또 다른 면은 RPC 스타일의 웹 서비스 지원입니다. WebLogic Server는 웹 서비스의 WSDL 설명을 바탕으로 JAX-RPC 스텁을 생성하기 위해 Ant 기반 도구를 제공합니다. 웹 서비스 클라이언트는 이렇게 생성된 스텁을 사용하여 서버측 동작을 나타내는 원격 인터페이스를 얻을 수 있습니다. Spring은 JaxRpcPortProxyFactoryBean을 제공하여 이러한 절차를 간소화합니다.

WebLogic Server 환경에 JaxRpcPortProxyFactoryBean을 제대로 구성하기가 약간 까다롭다는 사실을 알고 있으므로 시간을 절약하기 위해 이 코드 단편은 복잡한 형식을 포함하는 래핑(wrap)된 웹 서비스에 대해 프록시 생성을 구성하는 방법을 보여 줍니다.

대부분의 속성은 자명하고, 일부 속성은 다음과 같은 특성을 가집니다.

• serviceInterface는 Spring의 설정자 삽입의 부산물입니다. 이 클래스는 웹 서비스 동작을 나타냅니다.

• customProperties 속성은 맞춤형 WebLogic Server 웹 서비스 스텁 속성을 고려합니다.

• jaxRpcService 값은 WebLogic Server에서 생성된 JAX-RPC 구현 서비스로 설정되어 있습니다. JAX-RPC 서비스는 웹 서비스 인증을 담당하고 복잡한 형식 매핑을 로드합니다. 복잡한 형식 매핑 로드 기능을 충족시키려면 WebLogic Server의 JAX-RPC 서비스 구현을 Spring 빈으로 구성해야 합니다. 이렇게 하면 JAX-RPC 서비스 구성자를 실행할 수 있는데, 이곳으로 형식 매핑 파일이 로드됩니다.

JaxRpcPortProxyFactoryBean에서lookupServiceOnStartup 를 false로 설정하면 시작 시 JAX-RPC 서비스 조회 기능이 작동되지 않습니다. 대신 첫 번째 액세스를 하자마자 조회가 수행됩니다. 이러한 기능은 WebLogic Server서버와 신뢰성 있는 요청/응답 웹 서비스를 주고받는 클라이언트에게 필요합니다. 여기서 클라이언트도 웹 서비스여야 합니다. 이런 경우 종종 원래 클라이언트는 웹 서비스 클라이언트와 함께 배포됩니다. 애플리케이션 배포가 최종 마무리될 때까지 웹 서비스 활성화가 발생되지 않기 때문에 Spring의 컨텍스트 로드 시 클라이언트 웹 서비스를 이용할 수 없습니다.

<!-- reliable asynchronous Web service for sending new
  medical records to medrec -->
<bean id="reliableClientWebServicesPortType"
  class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean"
  lazy-init="true">
   <property name="wsdlDocumentUrl"
     value="http://${WS_HOST}:${WS_PORT}/ws_phys/PhysicianWebServices?WSDL"/>
   <property name="portName" value="PhysicianWebServicesPort"/>
   <property name="jaxRpcService">
      <ref bean="generatedReliableService"/>
   </property>
   <property name="serviceInterface"
     value="com.bea.physician.webservices.client.PhysicianWebServicesPortType"/>
   <property name="username" value="medrec_webservice_user"/>
   <property name="password" value="weblogic"/>
   <property name="customProperties">
      <props>
         <prop key="weblogic.wsee.complex">true</prop>
      </props>
   </property>
</bean>

<!-- allows the jaxRpcService class to execute its
  constructor which loads in type mappings -->
<bean id="generatedReliableService"
  class="com.bea.physician.webservices.client.PhysicianWebServices_Impl">
</bean>

자세한 내용은 WebLogic Server의 웹 서비스 호출 개요(Overview of Invoking Web Services) 및 Spring을 이용한 원격 지원 및 웹 서비스(Remoting and Web Services Using Spring)를 참조하십시오.

보안

WebLogic Server 보안 시스템은 다양한 보안 데이터베이스 또는 보안 정책을 처리하기 위해 사용자 정의할 수 있는 풍부한 보안 공급자를 제공하는 한편 J2EE 보안을 지원 및 확장합니다. 애플리케이션 프로그래머는 표준 J2EE 보안 이외에 고유한 확장자로 된 광범위한 어레이를 사용하여 애플리케이션이 보안 시스템과 밀접하게 통합되도록 합니다. WebLogic Server는 예를 들어, 일반 LDAP 서버, Active Directory, native Windows 및 기본 인증 솔루션이 대부분 포함된 인증 데이터베이스를 선택할 수 있는 몇 가지 보안 공급자와 함께 제공됩니다. 거의 모든 인증 데이터베이스, 권한 부여 메커니즘 및 자격 증명 매핑 서비스를 통합하기 위해 기본 공급자를 사용자 정의 공급자로 확대할 수 있습니다. webapps로 배포된 Spring 애플리케이션은 J2EE 보안을 사용하므로 애플리케이션을 변경하지 않고도 WebLogic Server 보안 이점을 얻을 수 있습니다.

또한 Seasoned Spring 사용자는 Acegi-Spring의 자체 보안 프레임워크를 인식합니다. 현재 애플리케이션에서는 Acegi, WebLogic Server 보안이 서로 독립적이기 때문에 이 중 하나 또는 둘 다를 사용할 수 있습니다. 이에 대해서는 나중에 자세히 설명합니다.

분산 트랜잭션

Spring은 트랜잭션 관리를 위한 인프라스트럭처를 제공합니다. 또한 Spring은 다양한 데이터베이스 벤더를 지원함은 물론 J2EE 벤더의 JTA 구현을 통해 분산 트랜잭션을 지원합니다. WebLogicJtaTransactionManager를 통해 Spring의 JTA 관리자를 WebLogic Server의 JTA 구현과 함께 작동하도록 구성할 수 있습니다.

WebLogicJtaTransactionManager는 책임을 바로 WebLogic Server의 Java Transaction API로 위임합니다. WebLogic Server의 JTA TransactionManager 인터페이스는 JNDI를 통해 클라이언트 및 빈 공급자가 사용할 수 있으며 Spring은 이러한 상호 작용을 관리합니다. 또한 트랜잭션 관리자는 트랜잭션의 범위를 지정할 수 있고 트랜잭션은 클러스터와 도메인 내에서 또는 그 사이에서 작동될 수 있습니다.

WebLogicJtaTransactionManager의 가장 강력한 기능은 엔터프라이즈 애플리케이션에서 분산 트랜잭션 및 2단계의 커밋 프로토콜을 관리하는 기능입니다. WebLogicJtaTransactionManager을 사용하여 애플리케이션은 WebLogic Administration Console을 통해 트랜잭션을 모니터링할 수 있습니다. 또한 WebLogicJtaTransactionManager는 데이터베이스별 고립 수준을 고려하므로 복잡한 트랜잭션 구성을 할 수 있습니다.

<!-- spring's transaction manager delegates to WebLogic
  Server's transaction manager -->
<bean id="transactionManager"   class="org.springframework.transaction.jta.WebLogicJtaTransactionManager">
   <property name="transactionManagerName"
     value="javax.transaction.TransactionManager"/>
</bean>

<!-- base transaction proxy for which medrec spring beans inherit-->
<bean id="baseTransactionProxy"   class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
  abstract="true">
   <property name="transactionManager" ref="transactionManager"/>
   <property name="transactionAttributes">
      <props>
         <prop key="activate*">
            PROPAGATION_REQUIRED</prop>
         <prop key="create*">
            PROPAGATION_REQUIRED</prop>
         <prop key="compose*">
            PROPAGATION_REQUIRED</prop>
         <prop key="deny*">
            PROPAGATION_REQUIRED</prop>
         <prop key="getRecord*">
            PROPAGATION_REQUIRED,readOnly</prop>
         <prop key="getPatient*">
            PROPAGATION_REQUIRED,readOnly</prop>
         <prop key="getLog*">
            PROPAGATION_NOT_SUPPORTED</prop>
         <prop key="process*">
            PROPAGATION_REQUIRED</prop>
         <prop key="save*">
            PROPAGATION_REQUIRED</prop>
         <prop key="send*">
            PROPAGATION_REQUIRED</prop>
      </props>
   </property>
< /bean>

<!-- single point of service for all medrec clients -->
<bean id="medRecClientServiceFacade"
  parent="baseTransactionProxy">
   <property name="target">
      <bean
        class="com.bea.medrec.service.MedRecClientServiceFacadeImpl">
         <property name="adminService">
            <ref bean="adminService"/>
         </property>
         <property name="patientService">
            <ref bean="patientService"/>
         </property>
         <property name="recordService">
            <ref bean="recordService"/>
         </property>
         <property name="recordXmlProcessorService">
            <ref bean="recordXmlProcessorService"/>
         </property>
      </bean>
   </property>
</bean>

자세한 내용은 WebLogic Server 애플리케이션의 트랜잭션 개요(Overview of Transactions in WebLogic Server Applications) 및 Spring에서 트랜잭션 일시 정지 구현(Implementing Transaction Suspension in Spring)을 참조하십시오.

Java Management Extensions

JMX(Java Management Extension)는 Java 애플리케이션을 모니터링하고 관리하기 위한 사양입니다. 이를 통해 일반 관리 시스템에서 애플리케이션을 모니터링하고, 애플리케이션에 대한 주의가 필요할 경우 이를 통보하고, 문제를 해결하기 위해 애플리케이션의 상태를 변경할 수 있습니다. Spring이 제공하는 광범위한 JMX 지원 중에는 MBeanServerConnectionFactoryBean을 통해 WebLogic Server의 MbeanServer를 제공하는 기능이 포함됩니다. MBeanServerConnectionFactoryBean은 편리한 팩토리이며 MBeanServerConnection은 이것의 부차적 결과입니다. 애플리케이션 배포 시 이러한 연결이 설정되고 빈을 참조하면 나중에 작동되도록 캐시됩니다.

WebLogic Server의 Runtime MBean Server를 반환하도록 MBeanServerConnectionFactoryBean을 구성할 수 있습니다. 그러면 모니터링, 런타임 컨트롤 및 특정 WebLogic Server 인스턴스의 활성 구성이 제공됩니다. 여기에는 WebLogic Server의 진단 프레임워크에 대한 액세스도 포함됩니다. 또한 Runtime Mbean은 런타임 Mbeans에 대한 액세스를 제공하고 현재 서버에 대한 활성 Mbeans구성을 제공합니다.

또한 WebLogic Server의 Domain Runtime MBean Server에 연결할 수 있도록 MbeanServerConnectionFactoryBean을 구성할 수 있습니다. Domain Runtime MBean Server는 애플리케이션 배포, JMS 서버 및 JDBC 데이터 소스와 같이 도메인 전체에 걸친 서비스에 대한 접근을 허용합니다. 또한 모든 런타임 Mbeans 및 도메인의 모든 서버에 대한 활성 MBeans 구성의 계층 구조를 액세스할 수 있는 단일 지점이기도 합니다. 더욱이 MBean Server는 관리되는 서버에 상주하는 Mbeans에 대한 단일 액세스 지점이기도 합니다.

WebLogic Server의 Edit MBean Server에 연결할 수 있도록 MBeanServerConnectionFactoryBean을 구성할 수도 있습니다. Edit MBean Server는 현재 WebLogic Server 도메인의 구성을 관리하기 위한 진입점을 제공합니다.

WebLogic Server의 Domain Runtime MBean Server는 배포 시 활성화되지 않습니다. 이런 사실 때문에 Spring의 느슨한 초기화를 사용하여 빈을 구성해야 호출할 경우 빈을 가져옵니다.

다음은 WebLogic의 MBean Servers에서 Spring의 MBeanServerConnectionFactoryBean을 구성하는 예입니다.

<!-- expose WebLogic Server's runtime
  mbeanserver connection -->
<bean id="runtimeMbeanServerConnection"
  class="org.springframework.jmx.support.MBeanServerConnectionFactoryBean">
   <property name="serviceUrl"      value="service:jmx:t3://${WS_HOST}:${WS_PORT}/jndi/weblogic.management.mbeanservers.runtime"/>
   <property name="environment">
      <props>
         <prop key="java.naming.security.principle">
            ${WS_USERNAME}</prop>
         <prop key="java.naming.security.credentials">
            ${WS_USERNAME}</prop>
         <prop key="jmx.remote.protocol.provider.pkgs">
            weblogic.management.remote</prop>
      </props>
   </property>
</bean>

자세한 내용은 WebLogic Server MBeans 이해(Understanding WebLogic Server MBeans) 및 Spring의 JMX 지원(JMX Support)을 참조하십시오.

지원

WebLogic Server 9.0 및 Spring 1.2.5를 시작하면 BEA는 WebLogic Server 기반의 Spring Framework의 지원 및 인증을 사용할 수 있습니다. 이러한 지원은 단순히 WebLogic Server에서 Spring 라이브러리의 건전성을 테스트하는 것이 아니라 BEA와 Spring Framework를 만들고 유지 관리를 담당하는 Interface 21의 강도 높은 노력과 공동 작업과 관련되어 있습니다. Spring 1.2.5에서 위에서 설명한 모든 기능 및 구성을 테스트했을 뿐 아니라 BEA와Interface 21의 공동 작업 결과 Spring 1.2.5에 일부 새로운 기능이 바로 도입되었습니다. 일부 기능은 WebLogic Server 자체를 수정하고 Spring 콤보 패치(combo-patch)로 사용하게 됩니다.

이러한 모든 내용 및 자세한 내용은 BEA 다운로드 사이트에서 이용할 수 있는 WebLogic Server 기반의 Spring 배포에서 이용할 수 있습니다.

향후 작업

앞으로 WebLogic Server 및 Spring Framework 간에 더욱 긴밀한 통합을 제공할 계획입니다. 몇 가지 구상 중인 아이디어가 있는데 그 중 가장 흥미로운 것은 다음과 같습니다.

• Spring 배포 유닛: Spring 애플리케이션은 일반적으로 webapps로 배포되지만, Spring 애플리케이션에 대한 전용 배포 유닛을 제공할 수 있을 것입니다.

• Acegi 및 WebLogic Server 보안 통합: Acegi는 Spring의 보안 프레임워크이며, 앞으로 이를 WebLogic Server의 엔터프라이즈 클래스 보안 프레임워크와 통합할 계획입니다.

• 지속성을 위한 EJB 3.0 사용: 일반적으로 Spring은 POJO를 다루기 때문에 Spring 빈을 유지하려면 일종의 객체 관계 매핑 기술 같은 것이 필요할 것입니다. EJB 3.0의 출현으로 WebLogic Server는 이러한 목적을 달성하기 위한 표준 메커니즘을 제공하게 됩니다

요약

Spring, WebLogic Server 및 이러한 두 기술의 통합에 대해 살펴보았습니다. 살펴본 바와 같이 Spring을 통해 개발자 생산성을 향상시킬 수 있고 WebLogic Server는 서비스의 애플리케이션 품질을 향상시킬 수 있습니다. 두 기술 모두 서로를 침해하지 않기 때문에 특정 기술의 복잡한 일에 시달리지 않고 애플리케이션의 비즈니스 기술을 개발하는 데에만 전력을 기울일 수 있습니다.

추가 자료

• BEA WebLogic Server 9.0 제품 설명서
• dev2dev BEA WebLogic Server 8.1 and 9.0 제품 센터
• The Spring Framework
• Spring에서 트랜잭션 일시 중지 구현(Implementing Transaction Suspension in Spring), 저자: Juergen Hoeller, dev2dev, 2005년 7월
• Spring으로 J2EE를 더 잘 활용하기(Better J2EEing with Spring), 저자: Peter Braswell, dev2dev, 2005년 7월

Andy Piper는 WebLogic Server 핵심 팀의 리드 엔지니어이며 전문 분야는 RMI-IIOP 및 WebLogic Server의 네트워킹 구현입니다.

Rod Johnson은 Spring Framework의 설립자이고 Java 및 J2EE에 관해 잘 알려진 전문가입니다. Rod는 전문적인 J2EE 및 Spring Framework 서비스를 주로 제공하는 컨설턴트사인 Interface21의 CEO입니다.

Chris Wall은 BEA Systems, Inc에서 선임 엔지니어로 근무하고 있습니다. Chris는 Medical Records 애플리케이션 등 WebLogic Server의 수많은 샘플 및 교육 자료 개발에 참여했습니다.

Nick Tran은 BEA systems의 애플리케이션 엔지니어이며 WLS 샘플 팀의 리더입니다.