블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

OO 차세대 시스템

WAS Architecture Blue Print (DRAFT)  

2009-06-28

Oracle Korea Consulting

Principal Consultant

Byungwook Cho (byungwook.cho@oracle.com)

 

 

Overview

본 아키텍쳐는 OO 차세대 시스템을 위한 웹로직 구성 아키텍쳐이다. OO 아키텍쳐 요구 사항에 따라서 구성한 아키텍쳐로 다음과 같은 전제 조건을 기반으로 한다. Ÿ          웹로직을 중심으로 설계할것           클라이언트는 웹이 아닌 윈도우 애플리케이션을 사용한다.

    100개의 웹로직 인스턴스가 동시 운영 될것으로 예측된다.         총 업무는 A업무 (4개), B관리 (4개), C관리 (4개) 로 구성된다.Ÿ          하드웨어는 IBM P6 시리즈를 사용하며, 총 예상 CPU수는 52장이며, 하드웨어 가상화 기능을 제공한다. 

Architecture Principals

본 아키텍쳐의 설계 기본 원칙은 다음과 같다.

1. 안정성

장애가 발생하였을 때도 장애 업무 이외의 업무는 정상적인 수행이 가능해야 하며 타 업무로 그 영향을 전파해서는 안된다.

2. 확장성

비즈니스 상황에 따라서, 전체 시스템의 용량 (동시 사용자수)나 기능 (서비스 수)를 아키텍쳐의 변화 없이 쉽게 확장할 수 있어야 한다.

3.유연성

비즈니스 변화에 대해서 유연하게 대처할 수 있어야 한다.

 

Conceptual Architecture

위의 세가지 Principal을 기반으로 설계된 Conceptual Architecture는 다음과 같다.


Application Grid

애플리케이션 그리드의 개념은 여러 개의 하드웨어를 모아서 비즈니스 로직을 제공하는 단일된 형태의 애플리케이션 집합체이다. 외부에서 보기에는 하나의 애플리케이션 집합체로 보이며 단일 접속점 (End Point)을 가지지만 실제로 내부에는 여러 개의 애플리케이션이 분리된 하드웨어에 분리된 형태로 배포되어 있다.

 하드웨어 가상화 개념을 응용하여 그리드 내부에서 업무의 비중과 중요도에 따라서 하드웨어 자원을 동적으로 재 배정하여 자원 사용의 효율성을 극대화 한다.

 새로운 기능이 추가될 때 마다 컴포넌트를 애플리케이션 그리드에 꼽는 (PLUG IN)하는 개념으로 비즈니스 컴포넌트를 추가할 수 있으며, 애플리케이션 그리드의 Infrastructure에는 그리드를 관리하기 위한 운영,관리,모니터링 기능(이하 OAM) 이 구현되어 있기 때문에, 개발자는 비즈니스 로직에만 집중하여 개발한후 그리드에 배포하면 OAM은 Infrastructure에 의해서 관리된다.

 

애플리케이션 그리드 아키텍쳐는 계층에 따라서 하드웨어/미들웨어(웹로직)/웹서버 3개의 계층으로 나뉘어서 분리된다.

 

(1)   하드웨어 아키텍쳐

하드웨어는 IBM AIX 중에 가상화를 지원하는 하드웨어를 사용한다. 가상화는 하나의 하드웨어내에 있는 여러개의 CPU와 메모리를 분할하여 사용할 수 있는 기능이다. 즉 하나의 하드웨어 자원을 조각으로 나누어서 업무별로 할당이 가능하다.

 

하드웨어 아키텍쳐 구성시에, 작은 하드웨어 여러 개를 사용하는 것보다, 가상화가 가능한 큰 하드웨어를 사용하는 것이 유리하다. 일반적인 국내 차세대 시스템의 경우 오픈후에, 안정화 기간을 거치면 통상적으로 CPU 평균 사용률이 40% 이하로 제대로 구성된 아키텍쳐에서는 20~30%대로 사용되는 경우가 많다. 반대로 부하가 몰리는 서버의 경우 CPU 사용률이 70~80%까지 육박하는 경우도 있다. 이러한 경우, CPU나 메모리 자원에 대한 효율적인 분할을 하기 위해서는 하드웨어를 물리적으로 옮겨서 새로 소프트웨어 시스템을 설치해야 하는데, 이 과정은 많은 시간과 검증 작업을 요구하며 또한 소프트웨어 라이센스 측면에서 문제를 유발할 수 있다. (하드웨어 추가는 소프트웨어 라이센스의 추가 구매를 의미한다.)

 이런 비효율성은 반대로 가상화를 지원하는 하드웨어를 사용했을 때 쉽게 해결된다.  업무의 부하량에 따라서 동적으로 CPU 자원을 재할당 하여 업무 부하에 적절하게 대응할 수 있고 CPU 재할당의 경우에도 별도의 하드웨어 작업(CPU를 빼서 다른 서버에 옮기는등의)이 없이 소프트웨어적인 설정만으로도 가능하기 때문에, 변경에 대한 영향도를 최소화 할 수 있다.

 

(2)   웹로직 구성 아키텍쳐

웹로직 구성상에 있어서는 다음과 같은 원칙을 따른다.

업무당 하나의 웹로직 도메인을 사용하며,하나의 도메인은 여러 개의 클러스터를 가질 수 있으며, 각 클러스터는 여러 개의 Managed Server로 구성된다. 각 Managed Server에는 1개 이상의 업무 애플리케이션이 배포될 수 있다.

 

1) 서버 분리를 통한 장애 전파성 제거

자바 기반의 장애 특성은 턱시도와 같은 TP Monitor와 다르게 모든 업무가 하나의 프로세스에서 돌아가는 특징을 가지고 있다. 이로 인해서 장애가 발생할 경우, 같은 프로세스에서 돌고 있는 다른 업무에도 영향을 줄 수 있다. (TP Monitor의 경우 업무별-SERVER로 프로세스가 나뉘어져서 기동되기 때문에 장애가 다른 업무에 전파되지 않고 국지화될 수 있는 장점을 가지고 있다.) 이와 같은 문제를 해결하기 위해서 WAS에서 여러가지 Work Manager나 Thread Pool 분리와 같은 여러가지 기능을 제공하는데, 이 역시도, 메모리 과사용이나 CPU 과 사용등에 대한 문제에서는 자유로울 수 없다.

 

가장 올바른 아키텍쳐 설계 방안은 TP Monitor와 같은 원리로, 업무별로 Manager Server를 분리하여 장애시 타 업무에 대한 장애 전파성을 제거하는 것이다.

 

2) 관리 포인트 증가에 대한 해결 방법

Managed Server를 업무별로 분할하여 운영할 경우, 그 만큼 많은 Managed Server가 운영되게 되고, 이는 관리 포인트의 증가로 귀결된다. 이런 관리상의 문제점을 해결하기 위해서, 웹로직을 클러스터링 기능을 사용할 수 있다. 클러스터링에서는 여러 개의 Managed Server가 있더라도 클러스터 단위로 configuration을 반영할 수 있는 기능이 있기 때문에, Managed Server의 수가 증가하더라도 실제로는 클러스터의 단위로 관리를 할 수 있기 때문에 관리에서 오는 복잡도를 감소 시킬 수 있다.

 

3) 클라이언트를 통한 상태 관리

업무별로 Managed Server를 나누는 경우 발생하는 문제점중의 하나가 Managed Server간에 Session이나 상태 정보가 공유가 안되는 문제점을 가지고 있다. 그러나 고객의 아키텍쳐 설계의 Assumption은 윈도우 클라이언트 기반의 Rich Client를 사용하기 때문에, 상태나 사용자 정보를 클라이언트에서 관리하도록 설계하여 서버간의 정보 공유를 서버에서 클라이언트로 이관함으로써 이를 극복할 수 있다.

 

(3)   웹서버 아키텍쳐

1) Endpoint에 대한 Location Transparency 의 제공

본 아키텍쳐에서 웹서버는 Application Grid로의 End point를 단일화 시켜주는 중요한 역할을 한다. Grid내의 여러 개의 Managed Server의 주소로 클라이언트가 직접 접근하는 것이 아니라 업무별로 배정된, 웹서버라는 단일 접속점을 통해서 Grid내의 Managed Server로 접근할 수 있게 해준다. (이는 Grid내의 Managed Server의 수가 증가하거나 감소하더라도, 접속점에 대한 변경을 없게 하여 Location Transparency를 보장할 수 있게 한다.)

 

2) 유연한 배포 구조의 제공

본 아키텍쳐에서의 웹서버 구성은 하나의 업무에 대해서 두 이상의 웹서버와 하나의 L4를 사용하도록 구성되어 있는데, 이는 애플리케이션의 배포의 용이성을 제공하기 위해서이다.

WAS의 기능에 상관없이 애플리케이션 개발과정상의 실수에 의해서 REDEPLOY 과정에 많은 문제를 일으킬 수 있는데, 이로 인해서 가장 좋은 REDEPLOY 방법은 DEPLOY후 RESTART하는 것이 가장 좋은 방법이다. 그러나 이 경우 해당 업무가 일시적으로 정지될 수 있는 위험도를 가지고 있기 때문에, 이 다운 타임을 최소화할 수 있는 아키텍쳐 설계가 필요하다.

2개의 웹서버중 하나의 웹서버를 다운 시키면 L4에 의해서 반대쪽 웹서버로만 부하가 가게 되고, 웹서버가 다운 되었기 때문에, 그에 연결된 Managed Server들은 사용자로부터 REQUEST를 받지 않는 상태가 된다. 이 상태에서 애플리케이션을 재배포한후 서버들을 재기동 시킨후, 반대족 웹서버도 번갈아서 같은 방식으로 재기동을 하게 되면 운영중에도 가장 안전한 방법으로 업무에 대한 정지 없이 재배포가 가능하게 된다.

 

Application Grid OAM (Operation, Administration, Monitoring)

OAM 기능은 애플리케이션 그리드에 대한 운영,관리, 모니터링 기능을 제공하는 인프라이다. 비록 고객의 요구 사항에서는 웹로직만으로 구성하는 것을 요청했으나, 아키텍쳐의 완성도를 위해서 OAM 모듈에 대한 기능을 추가하였다.

 

Configuration 관리

고객의 요구사항중의 하나는 100개이상의 웹로직 인스턴스를 운영 및 관리해야 한다. 비록 클러스터링을 통해서 관리 포인트를 줄일 수 있는 형태로 설계했지만, 많은 인스턴스에 대한 Configuration 관리는 매우 도전적인 과제중의 하나이다.

Oracle 제품중에 ACC (Application Configuration Console)은 단일 Console을 통해서 여러 Managed 서버와 도메인 그리고 클러스터에 대한 관리를 가능하게 해주며, Configuration에 대한 이력관리등을 통해서 애플리케이션 그리드에 대한 하나의 관리 기능을 제공한다.

 

시스템 상태 모니터링

전체 그리드에서 시스템의 상태를 일목요연하게 볼 수 있는 기능이 필요하다. CPU 사용률, 애플리케이션 관점에서의 병목 구간, Thread 상태, 응답 시간등에 대한 모니터링 기능이 필요한데, 이는 APM (Application Performance Monitoring)을 통해서 가능하다.

 

업무별 상태 모니터링

시스템 상태 모니터링이 애플리케이션 관점(기술 관점)이라면 업무별 상태 모니터링은 비즈니스 관점에서 애플리케이션 그리드를 모니터링 하는 것이다.

 업무별 응답시간, 사용률, 장애율등을 Oracle BAM (Business Activity Monitoring)을 이용하여 그래프로 가시화 하여, 업무의 운용 상황을 한눈에 파악할 수 있도록 한다.

 

Features

Application Grid 아키텍쳐의 특징을 다시한번 정리해보면 다음과 같다.

 

장애 전파 방지 

Ÿ          Managed Server 분리를 통한 장애 전파 방지

업무별로 Managed Server를 분리하여, Dead Lock이나 Lock 경합으로 인한 장애 전파 또는 메모리 과사용으로 인하여 다른 업무에 영향을 주는 요인을 제거하였다.

Ÿ          하드웨어 자원 분리를 통한 장애 전파 방지

기존 WAS 아키텍쳐에서는 JAVA 프로세스를 분리하더라도, 실제 CPU나 메모리등의 하드웨어 자원을 공유해왔기 때문에, 한 프로세스가 CPU를 과점유하기 시작하면 정상적인 다른 프로세스에게도 영향을 줬다.

그러나 이 아키텍쳐에서는 업무에 따라서 하드웨어 자원을 분리하여 할당하기 때문에,특정 업무가 CPU를 과점유한다하더라도, 다른 업무용으로 배정된 CPU 자원을 사용할 수 없기 때문에, 하드웨어 자원 점유에 의한 장애 전파를 방지한다.

유연하고 최적화된 하드웨어 리소스 운영

Ÿ          Managed Server의 수 조정을 통한 자원 배분

시스템의 사용량이 늘어날 때, 사용량이 늘어난 업무에만 Managed Server의 수를 늘려서 하드웨어 자원의 사용을 최적화 할 수 있다. 반대로 사용량이 적은 업무의 경우 Managed Server의 수를 줄여서 잉여된 자원을 다른 업무에 배정하여 전체 Application Grid의 하드웨어 사용 효율성을 극대화 한다.

Ÿ          가상화를 통한 CPU 및 메모리에 대한 유연한 배분

해당 업무에 메모리 사용량이 높거나 CPU 사용량이 높을때는 하드웨어 가상화 기능을 통해서

메모리 크기 한계 극복

Ÿ          업무별 분리를 통한 메모리 사용성의 극대화

자바 애플리케이션은 구조상의 한계상 통상적으로 1.5GB의 메모리만이 사용가능하다. (최대 3G). 그래서 사용자 수가 늘어나는 경우에는 전체 부하를 여러 개의 인스턴스로 분산 시켜서 메모리 사용량을 낮추어야 하는데, 이 아키텍쳐에서는 간단하게 Managed Server의 수만 늘려주는 것만으로 메모리에 대한 부하를 손쉽게 분산 시킨다.

       참고 : Managed Server 분리에도 불구하고, 더 많은 양의 메모리가 필요한 경우에는 Coherence Data Grid를 이용하여, 메모리 확장을 고려할 수 있다.

 

확장성 

Ÿ          웹서버를 이용한 Location Transparency의 제공

업무의 종류나 부하량 또는 사용자가 증가하는 것에 상관없이, 새로운 업무는 Application Grid에 추가로 배포될 수 있으며, 시스템의 용량도 하드웨어 증설만으로 큰 설정 변경 없이 손쉽게 증설이 가능하다. 시스템이 확장되더라도 Grid 밖에서 보기에는 동일한 End Point를 통해서 접근하는 것이기 때문에, 확장이 기존의 애플리케이션에 영향을 주지 않는다.

애플리케이션 배포의 유연성 

Ÿ          웹서버와 L4를 이용한 무정지 Clean redeploy 제공

앞서 설명한 바와 같이 L4와 2개 이상의 웹서버 구성을 통해서 가장 안전한 방법 (RESTART)으로 운영중 무정지 재배포를 지원한다.

 

본글은 http://bcho.tistory.com/366 에서 만든 ADF 기반의 JSF 애플리케이션을 배포하고 테스트 하기 위해서 웹로직 서버를 설정하고 애플리케이션을 배포하고 테스트 하는 방법입니다.

위 링크에 의해서 애플리케이션이 만들어져 있어야 하고 WebLogic 11g가 깔려있어야 합니다. (Oracle JDeveloper 11g를 깔면 같이 깔리게 됩니다.)

본 예제는 JSF(Java Server Faces)의 구현체중 하나인 Oracle ADF Faces를 이용하여 개발하는 예제입니다. 아주 간단하게 TEXT 박스에서 이름을 읽어서 출력하는 HELLO WORLD 예제입니다. 이클립스 기반 JSF 개발 환경 구축에 대해서 알아볼 수 있습니다.

환경 정보
- WebLogic 11g (JDevloper 11g에 포함됨)
- JDevloper 11g (ADF 라이브러리를 사용하기 위함) - http://www.oracle.com/technology/software/products/jdev/index.html

소스 코드는 를 참고하세요 
다음 강좌에서는 만들어진 JSF 애플리케이션을 웹로직을 설정하고 배포해서 테스트 하는 방법에 대해서 알아보겠습니다.

(동영상내의 글씨가 작아서 잘 안보이시면 확대해서 보세요. 조금 났군요.)

 

오라클 Coherence 가 그려내는

차세대 Java Enterprise Architecture

 

한국 오라클 컨설팅
Principal Consultant
조 병욱 (byungwook.cho골뱅이oracle.com)

 

서문 

2008년과 2009년의 SI 프로젝트 상황을 보면 의외로 사실상 실패하는 프로젝트의 비중이 늘어나고 프로젝트상에서 기술적인 문제가 발생하는 빈도가 늘어나고 있다. 특히 I사가 주 사업자로 참여한 프로젝트의 경우 오픈시에 항상 기술적인 문제점이 발생하고 있다. 이미 KOO 와 동XXX 와 프로젝트를 진행한 OO사 등이 그 사례라고 볼 수 있다. 진행사의 SI 능력에서 문제의 원인을 찾을 수 도 있지만, 근래에 진행되는 많은 프로젝트들이 유사한 문제점을 가지고 있는 것을 봤을때는 단순하게 수행사의 문제라고만 하기에는 어렵다

근래에 들어서 대부분의 SI 프로젝트의 경향을 보면 Spring,IBatis,Struts등과 같은 프레임웍을 사용하여 시스템을 개발하는 사례가 많다. 프레임웍은 생산성을 높여주고 시스템의 구조를 향상 시키는 역할을 하지만 반대로, 시스템의 구현 STACK이 깊어져서 시스템의 복잡도를 높이게 되고 이로 인해서 많은 기술적인 이슈를 야기 하게 된다

본 문서에서는 이 두가지 문제점을 자사의 Coherence Oracle Service Bus를 이용하여 해결할 수 있는 방법에 대해서 소개한다

기존 아키텍쳐의 문제점

J2EE가 소개된 이례 현재까지 가장 널리 사용되는 전통적인 아키텍쳐는 다음과 같다.


하나의 WAS 내에 UI와 비즈니스 로직을 같이 구현한다. 회사의 전체 업무가 크게 3개의 업무로 나뉘어진다고 해도, 3개의 업무가 모두 하나의 애플리케이션에 포함되어 배포되고 운영되어 왔다

메모리 사용량의 증가

이런 아키텍쳐가 가지고 있는 문제점은 무엇일까?
IT
비즈니스에 대한 요구 사항은 점점 더 증가 되어가고 있고 이는 더 많은 업무 로직과 기능을 요구하게 된다. 즉 업무 로직 자체가 커지게 되는데, 반대로 이를 지탱하고 있는 자바 언어 자체는 메모리의 한계를 벗어나지 못하고 있다. 통상적으로 32BIT JAVA에서 JAVA가 사용할 수 있는 메모리량은 최대 1.5G 내외가 된다. 물론 64Bit JVM을 사용해서 사용 가능한 메모리양을 확장할 수 는 있지만, JAVA가 가지고 있는 한계[i] 로 인하여 비대해지는 애플리케이션에 대한 문제가 많이 발생하고 있다.

실예로 모 화재 보험사 차세대 시스템의 경우에도 모든 업무가 하나의 애플리케이션에 함께 패키징되는 형태로 개발 및 배포 되어 많은 메모리 사용량을 요구하게 되었고 이로 인한 이슈가 있었다.

 또한 현재의 기술 흐름이 XML이나 OR Mapping과 같이 개발의 편의성과 우수한 구조를 제공하는 기술들이 소개되고 사용되지만 이것 역시 전통적인 애플리케이션에 의해서 메모리 사용량이 많이 늘어나게 된다

업무간의 장애 전파

기존 아키텍쳐의 다른 문제점중의 하나가 모든 업무가 똑같이 WAS인스턴스에 모두 같이 배포되기 때문에 장애가 발생하였을 때 그 장애가 다른 업무에도 영향을 준다는 것이다.[ii]

예를 들어 업무 C가 문제가 생겼을 때 같은 인스턴스에서 수행되고 있는 업무 A B에도 영향을 준다. 웹로직의 WorkManager등의 기능을 이용하여 장애를 최소화할 수 는 있지만 메모리 과사용이나 CPU 과점유등과 같은 Critical한 장애의 경우를 방지할 수 있는 방법이 없다

기존 아키텍쳐에 대한 개선 방안

그렇다면 기존 아키텍쳐에 대한 문제를 해결하기 위해서는 어떤 접근 방법이 필요할까?

해결 방안

해결 방안은 의외로 간단하다. 업무별로 WAS 인스턴스를 분리해서 배치하는 것이다.


 이런 아키텍쳐를 취할 경우 앞에서 제시된 두가지 문제점을 해결할 수 있다.

효율적인 메모리 사용

WAS 인스턴스별로 하나의 업무만 배포되기 때문에, 결과적으로 인스턴스당 요구되는 메모리 사용량이 적어진다.

장애 전파 방지

인스턴스가 물리적으로 완벽하게 분리되기 때문에, 특정 업무에서 장애가 발생하더라도 다른 업무에 전혀 영향을 주지 않는다.

 여기에 더해서 몇가지 장점을 더 얻을 수 가 있는데,

유연한 시스템 자원의 배분

업무 처리량에 따라서 유연하게 WAS 인스턴스 수를 조정할 수 있다. 업무 A의 처리량이 많을 경우에는 업무 A에 대한 WAS 인스턴스를 추가로 배정할 수 있고, 가상화를 지원하는 하드웨어의 경우에는 CPU를 업무 처리량이 많은 인스턴스에 배정하여 자원 사용의 효율성을 높일 수 있으며 업무에 대한 인스턴스가 명확하게 지정되어 있기 때문에 운영환경에서도 과부하시 자원(CPU)를 어느 프로세스에 적용해야 하는지가 명확해져서 시스템 운영의 효율성과 유연성을 확보할 수 있다

왜 개선 아키텍쳐를 사용하지 않는가?

그렇다면 이렇게 해결책이 명확한 아키텍쳐가 있음에도 불구하고 전통적인 엔터프라이즈 자바 애플리케이션에서 이런 아키텍쳐를 사용하지 않았을까? 문제는 이 아키텍쳐가 기술적인 한계성을 가지고 있다는 것이다.


애플리케이션은 업무 처리를 위해서 사용자에 대한 상태 정보등 (로그인 정보, 권한등)을 유지하게 되는데, 흔히 Http Session이라는 메모리 상에 이 정보를 저장한다. Session 정보는 클러스터간에는 서로 공유가 가능하지만 다른 클러스터 간에는 공유가 불가능 하다.

즉 업무 A를 위해 구성된 클러스터에서는 업무 B를 위해서 구성된 클러스터내의 사용자 상태 정보를 서로 공유할 수 없다는 것이다.

 완벽하게 분리되서 동작하기 때문에, 상태 정보역시 분리되어 버리는 결과를 낳게된다

Coherence를 이용한 아키텍쳐의 확장

이 아키텍쳐상의 한계를 Oracle Data Grid 솔루션인 Coherence로 해결할 수 있다.

Coherence Data Grid에 사용자 상태 정보를 정보와 업무간에 공유해야 하는 공유 데이터를 저장함으로써, 클러스터 구성 방식과 상관없이 업무 로직에서 사용자 상태 정보를 공유할 수 있게 됨으로써 구현하고자 하는 아키텍쳐를 실제로 구현할 수 있게 되었다.


 또한 Coherence를 이용한 Data Grid를 구축함으로써 기존에 사용자 상태 정보에 저장할 수 있는 데이터의 크기가 작았던 단점을 극복하고 좀더 큰양의 사용자 상태 정보를 유지할 수 있게 되었다[iii]

이 아키텍쳐에서는 업무로직을 가지고 있는 WAS Instance가 분리될 수 있어서 장애 전파성이 없어지고 확장이 무한적으로 가능할 수 있게 되며 업무에 따라서 WAS Instance 수나 CPU를 조정할 수 있기 때문에 유연한 자원 운용이 가능하다.


[i] Garbage Collection Time – 다 사용한 메모리를 반납하는 과정인데 이때 시스템이 일시적으로 정지하는 현상이 발생하는데,  이 정지 시간은 메모리의 크기에 비례한다

[ii] 클러스터링을 구성했다하더라도 업무 로직에 문제가 있는 경우에는 같은 업무 요청이 들어오게 되면 클러스터된 다른 인스턴스에서 같은 로직을 수행하기 때문에, 클러스터 여부에 관계없이 전체 시스템으로 장애가 전파 된다.

[iii] 실제 모 관공서 시스템의 경우 사용자 상태 정보에 많은 데이터를 유지했는데, 자바의 메모리 크기의 한계로 인하여 부하가 많을 경우에는 메모리 부족으로 인하여 장애를 유발하였다. 이런 문제를 해결하기 위해서는 기존의 아키텍쳐의 경우 하드웨어를 증설하여 더 많은 WAS 인스턴스를 운영하여 부하를 분산함으로써 WAS 인스턴스당 사용되는 사용자 정보 유지용 메모리 사용을 분산해야 하는데, Coherence를 도입할 경우에는 더 많은 메모리가 요구 될 경우 Coherence 용 서버만 확장하면 되기 때문에 시스템 증설시에 그 효율성이 매우 높아진다.

 

WebLogic Workshop에서 JAX-WS로, WebService 개발하기.
예전에 올렸던 동영상인데, 화질이 나쁘다는 피드백이 있어서 편집했는데. 어렵네요...

'프로그래밍 > XML 관련' 카테고리의 다른 글

XML 변환 성능  (0) 2009.04.17
Soap Handler  (0) 2009.04.17
WebLogic Workshop을 이용한 웹서비스 프로그래밍  (0) 2009.04.17
XMLBean  (3) 2008.12.22
JAX-WS를 이용한 쉬운 웹서비스 개발 방법  (0) 2008.12.12
XML에서 Namespace 제거하는 XSLT  (0) 2008.12.10
WebLogic Workshop 10.3 기준입니다. (9.X 이후는 비슷합니다.)

WLW에서 EJB 작성 방법

1.       EJB 프로젝트를 생성

2.       Project Facet에서 EJB Module 2.1을 선택, WebLogic EJBGen Support 를 선택

3.       EJB 코딩 (이때 메서드를 클릭하면 Property에 속성을 선택할 수 있는 창이 나옴)

4.       CLIENT JAR 생성 방법 : Project를 선택 > 오른쪽 버튼 > WebLogicEJB 선택후, > Jar setting EJB client.jar에서 use default 해제하고, 여기에 상대 경로 예를 들어 client/EJBclient.jar라고 써주면 EJB 를 export할때, ${EJB_PROJECT}/client/EJBclient.jar 파일이 생성 된다. (주의:프로젝트 생성시에 WebLogic EJBGen Support를 선택하지 않고, 다르게 생성한후 후에 Facet를 추가하면 제대로 Client가 generation되지 않는 경우가 있기 때문에 주의)

JAR 생성 방법 : Project 선택 > 오른쪽 버튼 > Export > EJB.JAR 생성하면 지정된 위치에 EJB가 패키징된 상태로 생성됨
WebLogic 10.3 에서, WebLogic Workshop (이클립스 기반 IDE)를 가지고
JAX-WS 기반으로 웹서비스를 생성하기
JAXB를 표준 데이타 포맷으로 사용하였고. 매우 심플하고 간단함


WebLogic 9.2 MP2 기준으로 작성
JMX 이용하여 XID를 입력하여 해당 트렌젝션에 대한 TM,RM,상태 정보들을 출력해주는 JSP 예제
==
<%@ page language="java" contentType="text/html;charset=UTF-8"%>
<%@ page import="java.util.*" %>
<%@ page import="javax.naming.*" %>
<%@ page import="javax.management.*" %>
<%@ page import="javax.management.remote.*" %>
<%@ page import="weblogic.management.runtime.*" %>

<%!
 public void printMap(Map map,JspWriter writer) throws Exception {
  for(Iterator i=map.keySet().iterator();i.hasNext();){
   Object key = i.next();
   writer.println(key+":"+map.get(key)+"\n<BR>");
  } 
 }
%>
<%
 // MBean 서버에 연결
 Hashtable h = new Hashtable();    
 
 h.put(Context.SECURITY_PRINCIPAL, "weblogic");     
 h.put(Context.SECURITY_CREDENTIALS, "weblogic" );     
 h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, "weblogic.management.remote");     

 JMXServiceURL serviceURL = new JMXServiceURL(
   "t3","localhost",7001,"/jndi/weblogic.management.mbeanservers.runtime");
 
    JMXConnector connector = JMXConnectorFactory.connect(serviceURL,h);
    MBeanServerConnection conn = connector.getMBeanServerConnection();
 
    ObjectName service = new ObjectName("com.bea:Name=RuntimeService,Type=weblogic.management.mbeanservers.runtime.RuntimeServiceMBean");
   
 // ServerRuntime 얻어오기
 ObjectName  serverRuntime = (ObjectName)conn.getAttribute(service, "ServerRuntime");

 // xid를 이용해서 jtaRuntime으로 부터 JTATransaction객체를 읽어온다.
 String xid = request.getParameter("xid");
 
 ObjectName jtaRuntime = (ObjectName)conn.getAttribute(serverRuntime,"JTARuntime");
 JTATransaction tx = (JTATransaction)conn.invoke(jtaRuntime,"getJTATransaction",
   new Object[] {new String(xid)},new String[] {"java.lang.String"} );

 if(tx == null){ out.println("No transaction exist");return;}

 // 해당 트렌젝션에 대한 정보 출력
 // 참고
 // http://edocs.beasys.com/wls/docs92/javadocs_mhome/weblogic/management/runtime/JTATransaction.html
 
 out.println("# UserProperties");
 out.println("<BR>");
 printMap(tx.getUserProperties(),out);
 
 out.println("# Tx started before :"+tx.getSecondsActiveCurrentCount());
 out.println("<BR>");
 out.println("# Status :"+tx.getStatus());
 out.println("<BR>");
 out.println("# Server & Status");
 out.println("<BR>");
 printMap(tx.getServersAndStatus(),out);
 out.println("# Resource & Status");
 printMap(tx.getResourceNamesAndStatus(),out);
 

%>
==