• 검색 결과가 없습니다.

Total flow = preFlow ∪ afterFlow

문서에서 R&D연구결과보고서 (페이지 125-129)

서비스 조합 알고리즘은 afterFlow를 재귀적으로 호출하고, 템플릿 아키텍처 타입에 따라서 서비스를 선택 및 조합하는 알고리즘이다. 서비스의 조합 과정은 아키텍처 타 입이 순차적인 흐름인 경우에 이루어지며, 다른 패턴들은 재귀적 호출을 통해 순차적 인 흐름으로 변환된다. (그림 3-49 참고)

(그림 3-49) Task Template Serialization

아키텍처의 타입이 순차적인 경우 getComponent 함수를 통하여 가장 앞에 존재하는 단위 태스크 단위를 추출하고, serviceSelection 함수를 통하여 로컬 최적화된 서비스를 선택한다. 서비스의 선택은 유틸리티 함수를 통하여 서비스들의 우선순위를 결정하고, 분배된 단위 태스크의 제약사항을 고려하여 사용 가능한 서비스를 선택하는 과정이다.

서비스 선택 이후에는 이미 조합된 서비스 흐름인 preFlow에 선택한 단위 태스크를 연결하고, QoS의 총합을 구한다. 또한 afterFlow에서 선택했던 단위 태스크를 제거하 고, TTASSA 함수를 재귀적으로 호출함으로써 나머지 서비스 흐름(afterFlow)에 대한 에 대한 서비스 선택을 진행한다.

아키텍처의 타입이 조건에 따른 진행일 경우, 확률p에 따라 서비스의 흐름을 선택하 고 알고리즘을 재귀적으로 호출한다. 반복적인 서비스 흐름의 경우에는 반복되는 횟수 가 k번이고, 반복되는 서비스의 흐름을 subFlow라고 가정 하였을 때, 서비스의 흐름은 k*subFlow의 형태로 순차적인 변환이 가능하다. 전체적인 서비스 흐름 관점에서는 afterFlow에서 subFlow만을 제거하여 나머지 서비스 선택을 진행한다. 서비스의 흐름 이 병렬적으로 진행되는 아키텍처 타입의 경우에는 서비스의 흐름을 단순하게 순차적

통하여 병렬적으로 진행되는 서비스 흐름들 중에서 가장 긴 길이를 갖는 흐름을 찾아 afterFlow에서 제거한다. 즉, 나머지 서비스 흐름에서 병렬흐름이 존재하는 구간을 제 외하고, 나머지 부분에 대해 재귀적으로 알고리즘을 호출하는 방식이다 (그림-3-50 참 고).

Algorithm: Task-Template-Architecture-aware Service Selection Algorithm (TTASSA) Input:

preFlow //already composited flow afterFlow // remain flow

arcType //architecture type of afterFlow Output:

preFlow //result of composited flow Procedure:

if(arcType = sequential) {

unitTask = getComponent(afterFlow);

afterFlow = selectedFlow(afterFlow, p);

}

afterFlow = afterFlow -subFlow;

}

else if(arcType = parallel) {

for number of parallel path do{

subFlow = selectedFlow(afterFlow, 1);

type = getArchitectureType(subFlow);

parallelFlows[] = TTASSA(preFlow,subFlow,type);

}

preFlow = preFlow + parallelFlows[];

afterFlow = afterFlow - parallelFunction(parallelFlows[]);

}if(afterFlow != NULL){

된 실행 시간을 측정함으로써 시뮬레이션 하였다. 본 연구에서는 하나의 단위 태스크 를 위해 발견될 수 있는 후보 컴포넌트 서비스 수의 최대치를 100으로 가정하였다. 10 개의 추상적 서비스로 이루어진 임의의 태스크 템플릿을 기반으로 하나의 추상적 서 비스에 대한 후보 서비스의 개수를 1∼100까지 증가시키며 제안된 서비스 선택 및 조 합기술의 성능을 측정하였으며 결과는 (그림 3-53)과 같다. 시뮬레이션을 위해 최소 1000개의 서로 다른 QoS 값을 가진 서비스들을 임의로 생성하였고 컴포넌트 서비스 별로 포함하는 QoS 요소의 개수도 관련 연구들의 경험에 근거하여 6개로 제한하였다.

성능 평가 작업은 Eclipse Java EE Indigo 1.4.0, JDK 1.6.0_26 환경에서 Java로 개발되 었으며 CPU core i5 2.80GHz, RAM 3.46GB으로 구성된 컴퓨팅 환경에서 수행되었다.

② 평가 결과

(그림 3-51) 제안된 방법의 성능 평가 결과

적인 서비스 조합 시간을 야기하지 않음을 확인할 수 있었으며, 실제 서비스 제공 환

(나) 설계

① 태스크 지향적 서비스 프레임워크 아키텍처

본 연구에서는 사용자에게 적합한 서비스를 동적인 방법을 제공하기 위한 방법으

문서에서 R&D연구결과보고서 (페이지 125-129)

관련 문서