선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- 상에서 구현하기 위해 Microsoft의 .NET Framework 와 WCF메시징 기법을 이용하여 웹서비스를 구현할 때어떤 기대효과가 있는지 연구 하였다.
- 본 논문에서는 이러한 SOA의 개념을 실제 애플리케이션 상에서 구현하기 위해 Microsoft의 .NET Framework 와 WCF메시징 기법을 이용하여 웹서비스를 구현할 때어떤 기대효과가 있는지 연구 하였다.
- 본 연구에서는 서비스 지향 아키텍처를 구현하기 위한 방법으로 .Net Framework 3.
제안 방법
- 모델링하였다. Message 클래스는 기본적으로 메시지 본문과 여러 메시지 헤더 및 속성을 모델링하며 각 메서 드는 메시지를 만들고 여러 헤더 및 속성을 조작하는 데 사용하도록 구성하였다. 그리고, WCF를 위한 메시지 클래스에서 XmlDictionaryReaderAVriter 표현을 지원하도록 하여 이를 통해 응용프로그램이 다양한 문서 표현과 성능 요구사항을 충족할 수 있도록 읽거나 기록할 수 있다.
- 0 과 WCF를 이용하여 SOA기반으로 작성한 주문 요청 /처리 프로그램과 .NET Framework 1.1 기반의 일반적인 웹 서비스 프로그램에 대해 서로 Request 처리 능력, 시스템 응답 속도 및 리소스 사용률을 비교 분석 흐}였다. 비교 분석을 확인하기 위해 ACT(application center test) 라는 부하벤치마크 툴과 Windows환경에서 제공하는 성능 카운터 분석 툴을 사용하여 테스트 시뮬레이션을 진행하였다.
- 3장에서 .NET Framework 3.0과 WCF를 이용한 SOA설계 방안을 제시한다. 4장에서는 J2EE기반으로 이미 구성되어 있는 주식거래 샘플 프로그램을 .
- 본 논문에서는 3장에서 설계한 .NET Framework 기반의 SOA서비스 모델 구성에서 Service Comectivity Layer 를 기준으로 워크플로우 서비스 또는 BPM(Business Process Management) 레이어에 메시지를 주고받기 위하여 WCF를 중심으로 정보를 전달하도록 구성하였다.
- 본 논문에서 제안한 .NET Framework 기반의 WCF 또한 이러한 WS-* 확장 사양을 간결하게 구현할 수 있도록 제안된 새로운 통합 서비스로 SOA 기반의 웹 서비스들이 서로 유연한 통신을 하고 애플리케이션 간의 상호운영성을 높일 수 있는 메시징 아키텍처를 제안 하였다. 이를 통해 SOAP, WS-Addressing 또는 기타 WS-* 프로토콜을 사용하지 않는 기존의 평범한 XML 서비스를 SOA기반의 웹 서비스로 쉽게 구현할 수 있으며 보다 정교하게 바인딩을 구성한다면 다른 프로토콜과 버전이 필요한 특정 통합 시나리오에 맞게 메시징 환경을 구축할 수 있다.
- 4장에서는 J2EE기반으로 이미 구성되어 있는 주식거래 샘플 프로그램을 .NET기반의 SOA환경으로 재설계하였다. 5장에서 설계된 프로그램에 대해 성능 평가를 하고 6장에서 결론 및 향후 연구과제에 대해 기술하였다.
- 위와 같은 기본적인 SOA 개념을 실제 .NET플랫폼 환경에서 서로 연관된 구성요소와 배치하기 위하여 서비스를 생성하고 각 서비스의 내용을 구성하는 부분, 기능에 따라 구분된 계층(Layer) 부분 그리고, 데이터와 호스팅 서비스를 담당하는 부분으로 구분하였다. 특히 계층 부분은 기능의 역할에 따라 다음과 같이 5가지로 분리하여 정의 하였다.
- .Net Framework 3.0과 WCF(windows communication foundation)를 기반으로 XML을 이용한 메시지 처리 방법을 제시하고, 레거시 환경의 웹 프로그램이나 JAVA기반의 플랫폼과 비교하여 성능 부하 테스트 결과를 확인 하였다.
- WCF 기반의 메시지가 SOA 서비스 모델의 각 레이어를 연결하고 정보를 주고받기위한 프로세스를 구현하기 위해 주문 요청 및 처리 프로그램을 샘플로 작성하였다.
- 가장 먼저 사용자 요청에 처리 능력을 확인하였다. 동시접속 브라우저 수를 샘플링하기 위해 일반적으로 기업용 웹서버에서 사용하는 서버스펙의 수준인 Intel P4, 2CPU 및 2GB의 서버에서 테스트 프로그램으로 작성한 애플리케이션에 동시접속 브라우저 수를 조금씩 증가한 결과 100명을 초과하는 경우, 더 이상 시스템의 응답이 나타나지 않는 것을 확인하였으며 본 연구에서 사용한 테스트 부하량은 100을 최대값으로 실험하였다.
- 1 기반의 일반적인 웹 서비스 프로그램에 대해 서로 Request 처리 능력, 시스템 응답 속도 및 리소스 사용률을 비교 분석 흐}였다. 비교 분석을 확인하기 위해 ACT(application center test) 라는 부하벤치마크 툴과 Windows환경에서 제공하는 성능 카운터 분석 툴을 사용하여 테스트 시뮬레이션을 진행하였다. ACT는 테스트 수행기간을 입력하고, 동시 접속자 수 를 통한 부하의 정도를 입력하여 응용프로그램 초당 처리 할 수 있는 능력을 비교할 수 있으며 Windows의 성능 도구는 테스트 시나리오에 따라 시스템의 응답 및 리소스 현황을 파악할 수 있다.
- 시뮬레이션 과정에서 응용프로그램의 응답 성능과 함께 애플리케이션이 플랫폼 상에서 얼마나 효율적으로 동작하는가를 살펴보기 위하여 일반적인 웹 서비스 프로그램과 SOA기반의 웹서비스가 시스템에서 사용하는 프로세서(CPU) 와 메모리의 사용량을 비교해 보았다. 시스템사용률을 확인하기 위한 테스트 과정에서 그림 10의 각 시나리오의 교차지점인 30수준의 부하를 주고 테스트를 진행한 하였다.
- 시스템사용률을 확인하기 위한 테스트 과정에서 그림 10의 각 시나리오의 교차지점인 30수준의 부하를 주고 테스트를 진행한 하였다. 동일한 부하 수준에서 상이한 시스템 성능 결과를 판단하기 위하여 사용자의 요청(Request)를 처 리 하는 과정에서 두 시나리오 모두 메모리 사용량은 안정적인 상태를 나타냈으나 SOA기반의 웹서비스가 좀 더 작은 메모리 사용량을 보여주었다.
- 이를 통해 SOAP, WS-Addressing 또는 기타 WS-* 프로토콜을 사용하지 않는 기존의 평범한 XML 서비스를 SOA기반의 웹 서비스로 쉽게 구현할 수 있으며 보다 정교하게 바인딩을 구성한다면 다른 프로토콜과 버전이 필요한 특정 통합 시나리오에 맞게 메시징 환경을 구축할 수 있다. 연구 내용의 테스트를 위해 주문 요청 /처리를 간단하게 처리하는 부분을 SOA형식의 비즈니스 서비스 모델로 정의하고 각 레이어에서는 WCF기반의 XML 메시지를 교환함에 따라 일반적인 웹서비스와 성능 차이를 확인하였다. ACT를 이용한 부하테스트 시뮬레이션 결과 일반적인 웹 서비스에 비해 SOA를 기반으로 한 .
- ACT는 테스트 수행기간을 입력하고, 동시 접속자 수 를 통한 부하의 정도를 입력하여 응용프로그램 초당 처리 할 수 있는 능력을 비교할 수 있으며 Windows의 성능 도구는 테스트 시나리오에 따라 시스템의 응답 및 리소스 현황을 파악할 수 있다. 테스트에 사용한 시스템 환경은, Microsoft Windows 2003 운영체제에서 IIS 6.0을 설치하였으며 동일한 사양의 서버에서 각각 프로그램을 구동시켜 테스트를 진행하였다.
이론/모형
- 주문 요청 /처리를 실행하는 비즈니스 서비스는 모든 트랜잭션에 대해 일관성을 가지고 데이터베이스의 종류에 상관없이 2-phase commit이 가능하도록 하기 위해 XA트랜잭션을 처리할 수 있도록 하고 System.Transactions 클래스를 사용하여 비즈니스 서비스 모델을 정의 하였다.
성능/효과
- ACT를 이용한 부하테스트 시뮬레이션 결과 일반적인 웹 서비스에 비해 SOA를 기반으로 한 .NET Framework 환경의 웹서비스가 보다 좋은 성능을 나타내는 것을 확인하였고 초기 부하량이 적은 환경에서는 일반적인 웹서비스 애플리케이션이 다소 좋은 결과를 나타내었으나 시스템에 부하가 심해질수록 응답 성능이 떨어지고 시스템의 CPU상태도 불안정하고 높아지는 것을 알 수 있 었다.
- 시뮬레이션 결과를 보면 사용자의 부하량에 관계없이 SOA 기반의 프로그램은 일관성 있는 성능 수치를 나타내고 있음을 그림 12를 통해 알 수 있다. 그리고 시스템에 적용한 부하 량이 10-20 사이에서는 일반적인 웹서비스가 평균 140% 정도 높은 수치를 나타냈으나 시스템에 부하가 50 이상 증가됨에 따라 SOA기반의 프로그램에서 155% 정도 향상된 처리 능력을 보여 주었다.
- 가장 먼저 사용자 요청에 처리 능력을 확인하였다. 동시접속 브라우저 수를 샘플링하기 위해 일반적으로 기업용 웹서버에서 사용하는 서버스펙의 수준인 Intel P4, 2CPU 및 2GB의 서버에서 테스트 프로그램으로 작성한 애플리케이션에 동시접속 브라우저 수를 조금씩 증가한 결과 100명을 초과하는 경우, 더 이상 시스템의 응답이 나타나지 않는 것을 확인하였으며 본 연구에서 사용한 테스트 부하량은 100을 최대값으로 실험하였다. 테스트를 진행하기 위해, 동시접속 브라우저 수를 10부터 20, 50 그리고 100으로 증가함에 따라 시스템의 반응을 살펴본 결과 사용자가 많을 때와 적을 때, 각 프로그램의 결과값에서 비교할 만한 차이가 나타났다.
- 시스템사용률을 확인하기 위한 테스트 과정에서 그림 10의 각 시나리오의 교차지점인 30수준의 부하를 주고 테스트를 진행한 하였다. 동일한 부하 수준에서 상이한 시스템 성능 결과를 판단하기 위하여 사용자의 요청(Request)를 처 리 하는 과정에서 두 시나리오 모두 메모리 사용량은 안정적인 상태를 나타냈으나 SOA기반의 웹서비스가 좀 더 작은 메모리 사용량을 보여주었다. 시스템의 CPU 점유율은 일반적인 웹 서비스 환경에서 평균 85% 이상의 높은 리소스 사용률을 나타내어 SOA기반의 웹서비스보다 30% 높게 나타났다.
- 동일한 부하 수준에서 상이한 시스템 성능 결과를 판단하기 위하여 사용자의 요청(Request)를 처 리 하는 과정에서 두 시나리오 모두 메모리 사용량은 안정적인 상태를 나타냈으나 SOA기반의 웹서비스가 좀 더 작은 메모리 사용량을 보여주었다. 시스템의 CPU 점유율은 일반적인 웹 서비스 환경에서 평균 85% 이상의 높은 리소스 사용률을 나타내어 SOA기반의 웹서비스보다 30% 높게 나타났다.
- 동시접속 브라우저 수를 샘플링하기 위해 일반적으로 기업용 웹서버에서 사용하는 서버스펙의 수준인 Intel P4, 2CPU 및 2GB의 서버에서 테스트 프로그램으로 작성한 애플리케이션에 동시접속 브라우저 수를 조금씩 증가한 결과 100명을 초과하는 경우, 더 이상 시스템의 응답이 나타나지 않는 것을 확인하였으며 본 연구에서 사용한 테스트 부하량은 100을 최대값으로 실험하였다. 테스트를 진행하기 위해, 동시접속 브라우저 수를 10부터 20, 50 그리고 100으로 증가함에 따라 시스템의 반응을 살펴본 결과 사용자가 많을 때와 적을 때, 각 프로그램의 결과값에서 비교할 만한 차이가 나타났다. 다음은 시뮬레이션 과정에서 프로그램 환경에 따라 시스템에 적용한 부하 량과 RPS(Request per Second) 수치 결과를 나타낸다.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.