KR20210057679A - 크로스도메인 확장형 워크플로우 엔진 프레임워크 - Google Patents

Abstract

본 발명의 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 구성된 엔진 컨테이너는, 다수의 REST(Representational State Transfer) API(Application Programming Interface)와 각각 연동하는 다수의 오퍼레이터; 클라이언트의 요청에 따라, 상기 다수의 오퍼레이터를 순차적으로 호출하는 실행기; 및 상기 다수의 오퍼레이터와 상기 실행기의 동작을 제어하는 제어기를 포함하고, 각 오퍼레이터는, 상기 실행기로부터 전달된 URL(Uniform Resource Locator) 정보를 이용하여 해당 REST API를 호출하고, 상기 호출한 해당 REST API를 통해 제공된 데이터를 처리하여 획득한 처리 결과를 다음 오퍼레이터로 전달하는 파이프라인 방식으로 동작한다.

Description

크로스도메인 확장형 워크플로우 엔진 프레임워크{workflow engine framework for cross-domain extension}

본 발명은 서로 다른 업무 도메인, 목적 도메인, 또는 공간 도메인을 융합하기 위한 워크플로우의 구성에 관한 것이다.

최근 주목받고 있는 스마트 제조업은, 서로 다른 물리적 공간들에서 수행되는 서로 다른 업무들 또는 서로 다른 목적들을 연계하여 최적의 결과를 도출하는 크로스도메인 지능형 서비스를 기반으로 한다.

크로스도메인 지능형 서비스를 제공하기 위해서는, 서로 다른 공간 도메인들, 서로 다른 업무 도메인들 및/또는 서로 다른 목적 도메인들을 융합하고 동시에 데이터 발생 상태 또는 환경 변화에 적응적인 워크플로우(workflow) 구성이 필요하다.

또한, 서로 다른 공간 도메인들, 서로 다른 업무 도메인들 및/또는 서로 다른 목적 도메인들을 유기적으로 실행 및 제어하기 위한 오케스트레이션(orchestration) 기술이 필요하다.

본 발명은 하나의 도메인 내에서 구성된 워크플로우를 확장하여, 서로 다른 공간 도메인, 서로 다른 업무 도메인 및/또는 서로 다른 목적 도메인에 공통으로 적용할 수 있는 크로스도메인 확장형 워크플로우를 구성하기 위한 시스템 및 이의 오케스트레이션 방법을 제공하는 데 그 목적이 있다.

본 발명의 전술한 목적 및 그 이외의 목적과 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부된 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다.

상술한 목적을 달성하기 위한 본 발명의 일면에 따른 엔진 컨테이너는, 프로세서를 포함하는 컴퓨팅 장치에 의해 실행되는 크로스도메인 확장형 워크플로우 엔진 프레임워크(이하, '워크플로우 엔진 프레임워크')에서 사용자에 의해 정의된 워크플로우 명세에 따라 생성된 것으로서, 상기 엔진 컨테이너는, 서로 다른 목적 도메인에서 제공하는 서로 다른 서비스들을 융합하기 위한 융합 지능 서비스를 제공한다.

구체적으로, 상기 엔진 컨테이너는, 다수의 REST(Representational State Transfer) API(Application Programming Interface)와 각각 연동하는 다수의 오퍼레이터; 클라이언트의 요청에 따라, 상기 다수의 오퍼레이터를 순차적으로 호출하는 실행기; 및 상기 다수의 오퍼레이터와 상기 실행기의 동작을 제어하는 제어기를 포함하고, 각 오퍼레이터는, 상기 실행기로부터 전달된 URL(Uniform Resource Locator) 정보를 이용하여 해당 REST API를 호출하고, 상기 호출한 해당 REST API를 통해 제공된 데이터를 처리하여 획득한 처리 결과를 다음 오퍼레이터로 전달하는 파이프라인 방식으로 동작한다.

본 발명에 따르면, 일원화된 워크플로우 구성방식에 의해 하나 이상의 물리적 공간 도메인, 하나 이상의 업무 도메인, 하나 이상의 목적 도메인 간 워크플로우를 정의하고 실행 및 제어할 수 있는 이점이 있다.

또한, 본 발명에 따르면, 스마트한 생산, 제조, 공정을 필요로 하는 지능형 서비스를 제공하기 위해서는 물리적 공간 도메인 간의 협력형 워크플로우, 서로 다른 업무 또는 서로 다른 목적 도메인 간 융합 가능한 워크플로우, 데이터 발생 상태나 환경의 변화에 적응적인 워크플로우를 구성하고 이를 유기적으로 실행/제어하기 위한 오케스트레이션 기술을 제공함으로써, 스마트 시티, 스마트 농장, 스마트 공공 등 다양한 분야에서 폭 넓은 지능형 서비스의 제공이 가능하다.

도 1은 본 발명의 실시 예에 따른 크로스도메인 확장형 워크플로우 엔진 프레임워크의 구성 요소들을 나타내는 블록도.
도 2는 도 1에 도시한 편집부의 구성을 설명하기 위한 GUI 화면을 도시한 도면이다.
도 3은 본 발명의 일 실시 예에 따른 크로스도메인 확장형 워크플로우를 실행하기 위한 엔진의 구성도이다.
도 4는 본 발명의 실시 예에 따른 파일시스템 기반의 단일 엔진 구성을 도시한 도면이다.
도 5는 도 4에 도시한 파일시스템 기반의 단일 엔진 구성을 이용하여 크로스도메인 확장형 워크플로우를 구성하기 위한 엔진의 구성도이다.
도 6은 도 5에 도시한 엔진 구성의 다른 예를 도시한 엔진의 구성도이다.
도 7은 본 발명의 실시 예에 따른 크로스도메인 확장형 워크플로우 기반의 협력형 지능 서비스를 제공하는 방법을 설명하기 위한 도면이다.
도 8은 본 발명의 일 실시 예에 따른 서로 다른 업무 및 목적 도메인들에서 각각 제공하는 서비스들을 융합하는 융합 지능 서비스를 정의하기 위한 엔진(엔진 컨테이너)의 구성도이다.
도 9는 본 발명의 다른 실시 예에 따른 서로 다른 업무 및 목적 도메인들에서 제공하는 서비스들을 융합하는 융합 지능 서비스를 정의하기 위한 엔진(엔진 컨테이너)의 구성도이다.
도 10 내지 14는 도 8 및 9에서 도시한 융합 지능 서비스를 위한 엔진의 내부 처리 절차를 설명하기 위한 도면들이다.
도 15는 도 13에 도시한 집계 기능을 갖는 오퍼레이터를 포함하는 엔진 구성을 이용하여 배관 누출(pipe leakage) 탐지와 관련된 워크플로우 서비스 시나리오를 설명하기 위한 도면이다.
도 16은 도 14에 도시한 룩업 테이블을 갖는 오퍼레이터를 포함하도록 구성된 엔진 구성을 이용하여 대화 생성과 관련된 워크플로우 서비스 시나리오를 설명하기 위한 도면이다.
도 17은 본 발명의 실시 예에 따른 융합 지능 서비스와 관련된 예측 모델을 주기적으로 업데이트 하기 위한 하나 이상의 워크플로우를 실행하고 제어하는 오케스트레이션 방법을 설명하기 위한 도면이다.

본 명세서에 개시되어 있는 본 발명의 개념에 따른 실시 예들에 대해서 특정한 구조적 또는 기능적 설명들은 단지 본 발명의 개념에 따른 실시 예들을 설명하기 위한 목적으로 예시된 것으로서, 본 발명의 개념에 따른 실시 예들은 다양한 형태로 실시될 수 있으며 본 명세서에 설명된 실시 예들에 한정되지 않는다.

이하, 실시예들을 첨부된 도면을 참조하여 상세하게 설명한다. 그러나, 본 발명이 이러한 실시예들에 의해 제한되거나 한정되는 것은 아니다.

도 1은 본 발명의 실시 예에 따른 크로스도메인 확장형 워크플로우 엔진 프레임워크의 구성도이다.

도 1을 참조하면, 본 발명의 크로스도메인 확장형 워크플로우 엔진 프레임워크(100)는 프로세서를 탑재한 컴퓨팅 장치에 의해 프로그래밍되거나 실행되는 소프트웨어 모듈 또는 이러한 소프트웨어 모듈을 내장한 하드웨어 모듈로 구현될 수 있다.

크로스도메인 확장형 워크플로우 엔진 프레임워크(100, 이하, '엔진 프레임워크'라 함)는 기본적으로 프론트 엔드부(10), 자원 관리부(20), 시스템 구성부(30), 시스템 제어부(40) 및 응용부(50)를 포함한다. 도 1에서는 편집부(5)가 더 도시된다.

편집부(5)는 실행할 작업(워크플로우)의 구조와 명세를 작성하는 기능을 제공하는 소프트웨어 모듈 또는 이러한 소프트웨어 모듈을 내장한 하드웨어 모듈일 수 있다.

프론트 엔드부(10)는 편집부(5)에 의해 작성된 작업(워크플로우)의 구조와 작업(워크플로우)의 명세를 엔진 프레임워크(100)로 전달하는 기능을 제공하는 소프트웨어 모듈 또는 이러한 소프트웨어 모듈을 내장한 하드웨어 모듈일 수 있다.

자원 관리부(20)는 워크플로우를 정의하는데 필요한 다양한 자원을 등록, 유지 및 관리하는 기능을 제공하는 소프트웨어 모듈 또는 이러한 소프트웨어 모듈을 내장한 하드웨어 모듈일 수 있다.

워크플로우를 정의하는데 필요한 자원은, 예를 들면, 사용자가 편집부(10)를 통해 작성할 워크플로우 명세(워크플로우를 구성하는 하나 이상의 엔진들로 구성된 명세) 상에서 각 엔진 컴퍼넌트들을 정의하기 위한 속성과 관련된 속성명세 컴퍼넌트, 워크플로우 실행을 수행할 엔진의 구성품에 해당하는 엔진 컴퍼넌트, 그리고 이전에 작성된 워크플로우 명세 인스턴스 등을 포함하는 것일 수 있다.

시스템 구성부(30)는 워크플로우 속성명세를 조립하고, 워크플로우 실행에 필요한 엔진 컴퍼넌트들을 동적으로 조합하고, 워크플로우를 수행하는 엔진 인스턴스(이하, '엔진'과 혼용됨)를 생성하는 기능을 제공하는 소프트웨어 모듈 또는 이를 내장한 하드웨어 모듈일 수 있다.

시스템 제어부(40)는 자원관리부(20), 시스템 구성부(30), 응용부(50) 및 시스템 구성부(30)에 의해 생성된 엔진의 실행을 제어하는 기능을 제공하는 소프트웨어 모듈 또는 이를 내장한 하드웨어 모듈일 수 있다.

시스템 구성부(30)와 시스템 제어부(40)는 하나의 모듈로 통합될 수 있으며, 이 경우, 통합된 하나의 모듈은 '운영 제어부' 또는 '오케스트레이션부'로 지칭될 수 있다.

응용부(50)는 편집부(5)를 통해서 작성된 워크플로우 명세를 실행하기 위해 생성된 엔진 인스턴스들을 관리하고, 엔진 인스턴스들의 실행에 따라 수집 또는 가공된 데이터들을 저장하고, 저장된 데이터들의 접근을 제어하는 기능을 제공하는 소프트웨어 모듈 또는 이를 내장한 하드웨어 모듈일 수 있다.

워크플로우 엔진 프레임워크(100)에서, 사용자는 원하는 시스템을 만들기 위해 하나 이상의 엔진으로 구성되는 워크플로우를 정의한다. 이때 워크플로우는 하나 이상의 엔진에 대한 정의로 구성된다.

엔진에 대한 정의는 엔진 컴퍼넌트들을 담기 위한 엔진 컴퍼넌트 컨테이너와 엔진 컴퍼넌트 컨테이너에 담길 엔진 컴퍼넌트의 조합일 수 있다.

엔진 컴퍼넌트 컨테이너는 하나 이상의 입력기(reader) 컴퍼넌트, 출력기(writer) 컴퍼넌트, 실행기(runner) 컴퍼넌트, 처리기(operator) 컴퍼넌트, 제어기(controller) 컴퍼넌트의 조합일 수 있다.

하나 이상의 입력기 컴퍼넌트, 출력기 컴퍼넌트, 실행기 컴퍼넌트, 처리기 컴퍼넌트, 제어기 컴퍼넌트들은 각각 컴퍼넌트의 성질을 나타내는 속성을 정의하기 위한 속성명세 컴퍼넌트와 컴퍼넌트들의 실제 구현체에 해당되는 실행 컴퍼넌트의 조합으로 만들어진다.

실행 컴퍼넌트는, 예를 들면, Java, C++ 등의 클래스에 해당되는 것이고, 속성명세 컴퍼넌트는 클래스의 생성자에 포함될 수 있는 생성자 파라미터 또는 생성자 파라미터를 담는 클래스에 해당된다.

본 발명에서는 이러한 방식으로 생성된 하나 이상의 엔진에 대한 워크플로우가 정의됨으로써, 서로 다른 업무 또는/및 서로 다른 목적 도메인 간의 융합 가능한 워크플로우와 데이터 발생 상태나 환경의 변화에 적응적인 워크플로우를 구성할 수 있다.

이하, 도 1에 도시한 각 구성들에 대해 보다 상세히 설명하기로 한다.

편집부(5)는 원하는 업무에 대한 세부 도메인을 정의하고 각 도메인에 대하여 처리할 작업 구조(워크플로우 구조)를 정의한다.

또한 편집부(5)는 정의된 작업 구조에 따라 엔진 컴퍼넌트(들)를 선정하여 워크플로우 실행 흐름을 정의하고, 각 엔진 컴퍼넌트들의 명세(작업 명세 또는 워크플로우 명세)를 작성하는 기능을 제공한다.

이를 위해, 편집부(5)는 프레임워크(특히, 자원관리부(20))로부터 속성명세 컴퍼넌트와 엔진 컴퍼넌트를 조회할 수 있다.

여기서 '작업 구조'는, 예를 들면, 특정 사물인터넷 플랫폼으로부터의 데이터 수집, 데이터 처리, 학습 등의 과정을 구조화한 것이며, 이들을 순차적으로 처리하는 것은 워크플로우 실행흐름에 해당될 수 있다.

'컴퍼넌트들의 명세(작업 명세 또는 워크플로우 명세)'는, 데이터를 어디로부터 가져와서 어떤 처리과정을 거치고 어디로 내보낼 것인지에 대한 작업을 수행하기 위해, 어떤 디바이스로부터 데이터를 수집할 것인지, 데이터의 연결방법은 무엇인지, 전달받은 데이터를 메모리에 둘 것인지 저장소에 넣을 것인지, 메모리 정보는 무엇인지, 저장소 위치는 어디인지 등, 각 요소 컴퍼넌트들에 대한 구체적인 정의 사항을 의미한다.

사용자(데이터 과학자, 모델 개발자, 비즈니스 개발자 등)는 편집부(5)를 통해, 워크플로우를 구성하는 엔진 컴퍼넌트와 그 엔진 컴퍼넌트의 특성을 결정하는 파라미터들을 정의할 수 있는 속성명세 컴퍼넌트를 규약에 따라 정의하고, 또한, 컴퍼넌트와 속성명세의 쌍을 정의하고 편집할 수 있다.

편집부(5)의 구성을 설명하기 위한 GUI 화면(71)의 예가 도 2에 도시된다.

도 2를 참조하면, GUI 화면(71)은 기능 메뉴(72), 엔진유형 선택부(73), 컴퍼넌트 선택부(74), 컴퍼넌트 속성 조회/편집부(75), 워크플로우 인스턴스 저장/조회부(76)를 포함하도록 구성될 수 있다.

기능 메뉴(72)는 편집부(5)가 제공할 수 있는 각종 기능들을 선택하는 메뉴로서, 예를 들어, New(워크플로우 신규작성), Open(저장된 워크플로우 불러오기), Save(워크플로우 저장), Run(워크플로우 실행), Result(실행결과 보기), Help(도움말) 등의 기능을 선택하는 메뉴로 구성될 수 있다.

엔진유형 선택부(73)는 각종 엔진 유형을 제시하고 사용자가 이들 중 필요한 것들을 선택할 수 있게 하는 기능을 제공한다.

엔진 유형으로, 예를 들면, 실시간 스트림 처리 엔진, 배치 분석 엔진, 요구형(on-demand) 데이터처리 엔진, 평가 엔진, 스트림 기계학습 예측 엔진, 요구형 융합 서빙 엔진 등이 있을 수 있다.

컴퍼넌트 선택부(74)는 사용자가 컴퍼넌트 타입과 각 타입별 엔진 컴퍼넌트를 선택할 수 있도록 컴퍼넌트 타입별로 다양한 엔진 컴퍼넌트 목록을 제공한다. 아래 표 1은 컴퍼넌트 선택부(74)에서 제시되는 컴퍼넌트 타입과 엔진 컴퍼넌트 목록의 예시이다.

컴퍼넌트 타입	엔진 컴퍼넌트
Reader(입력기)	FileReader HttpServerReader Kafka Reader MongodbReader ...
Writer(출력기)	FileWriter KafkaWriter MongodbReader ...
Controller(제어기)	SparkSessionController SparkSessionStreamController ...
Runner(실행기)	SparkRunnerTensoflowRunner ...
Operator(처리기)	MinMaxScaler Aggregator ...

컴퍼넌트 속성 선택/편집부(75)는 컴퍼넌트 선택부(74)에서 선택된 엔진 컴퍼넌트의 속성(Properties)들이 제시되고 사용자는 속성을 조회하여 이를 선택 및 편집할 수 있다.

워크플로우 인스턴스 선택부(76)는 기 제작된 워크플로우가 저장된 목록을 표시하는 기능을 제공한다. 이들 중에서 재활용을 원하는 워크플로우를 선택하여 재편집을 하거나, 그대로 프레임워크(100)에 실행요청을 할 수 있다. 재활용의 단위는 워크플로우 전체일 수도 있고, 또는 워크플로우에 포함된 단일 엔진별로 재활용하여 편집이나 실행에 활용할 수도 있다.

편집부(5)에서 워크플로우 명세 화일이 만들어지면, 그 워크플로우 명세 화일이 엔진 프레임워크(100)의 내의 시스템 구성부(30)로 제출(입력)된다. 이때, 프론트 엔드부(10)가 워크플로우 명세를 입력받아 시스템 구성부(30)에 전달하는 역할을 할 수 있다.

프론트 엔드부(10)는 사용자 요청에 따라 프로세스의 실행을 매개하는 역할을 수행하고, 사용자관리나 저장소 관리 등의 다양한 요청에 대응하는 역할을 수행한다.

프론트 엔드(10)는, 예를 들면, 일반적인 어플리케이션 서버, 웹기반의 REST API를 제공하는 웹어플리케이션 서버, 또는 일반적인 소켓통신 기반의 수신자(listener) 모듈을 포함하는 시스템일 수 있다.

경우에 따라서 프론트엔드(77)는 편집부(10) 또는 프레임워크(100)를 구성하고 있는 백엔드와 상이한 네트워크 상에서 실행되는 것일 수 있다.

다시 도 1을 참조하면, 엔진 프레임워크(100) 내의 자원 관리부(20)는 워크플로우를 정의하는데 필요한 다양한 자원을 등록, 유지 및 관리하는 기능을 제공하는 동시에 워크플로우의 실행에 필요한 컴퍼넌트들을 관리하는 기능을 제공한다.

이를 위해, 자원 관리부(20)는 응용 자산 등록 관리부(22), 엔진 컴퍼넌트부(24) 및 워크플로우 인스턴스 명세 관리부(26)를 포함한다.

응용 자산 등록 관리부(22)는 워크플로우를 구성하는데 사용될 자원이나 부가 정보들을 등록, 유지 및 관리한다.

응용 자산 등록 관리부(22)에 의해 관리되는 응용 자산은, 예를 들면, 머신런닝이나 데이터분석에 사용될 데이터셋(dataset), 머신러닝의 훈련을 위한 훈련 코드(training code), 훈련을 통해 생성한 머신러닝/딥러닝 기반 예측모델 또는 기타 예측알고리즘, 파이썬과 같이 특정 언어로 구현된 알고리즘 또는 코드, 컨테이너 이미지(container image), 내부 또는 외부에 존재하는 서비스 API, 연동 플랫폼 정보, 연동 시스템에 대한 인증(authentication)에 필요한 정보, 데이터의 발생지 정보, 데이터의 구독(subscription) 정보 등을 포함한다.

엔진 컴퍼넌트부(24)는 자원 관리부(20)에 의해 관리되는 속성명세 컴퍼넌트와 엔진 컴퍼넌트가 물리적으로 또는 가상적으로 저장되는 공간을 제공한다.

워크플로우 인스턴스 명세 관리부(26)는 기존에 작성되어 저장된 워크플로우 명세 인스턴스를 관리한다. 이러한 워크플로우 명세 인스턴스 관리부(26)는 편집부(5)의 요청에 따라 (가령, 도 2의 워크플로우 인스턴스 선택부(76)를 통해) 워크플로우 명세 인스턴스를 추후에 활용할 수 있도록 보관 및 관리한다.

그 밖에 도면에는 도시하지 않았으나, 자원 관리부(20)는 워크플로우 인스턴스의 컴퍼넌트 특성 또는 속성을 결정짓는 속성명세가 포함된 속성명세 컴퍼넌트와 그 목록을 관리(업데이트 포함)하는 속성명세 컴퍼넌트 관리부와 실행을 위한 컴퍼넌트(엔진 컴퍼넌트)들과 그 목록을 관리(업데이트 포함)하는 엔진 컴퍼넌트 관리부를 더 포함하도록 구성될 수 있다.

시스템 구성부(30)는 작성된 워크플로우의 실행에 필요한 컴퍼넌트를 생성하는 기능을 제공한다. 시스템 구성부(30)는 프론트엔드(10)로부터 입력된 작업 구조(워크플로우 구조)와 작업 명세(워크플로우 명세)에 따라 필요한 엔진 컴퍼넌트 컨테이너들을 구성하여 엔진 인스턴스를 생성한다.

이를 위해, 시스템 구성부(30)는 워크플로우 구성부(34) 및 로그 관리부(36)를 포함한다.

워크플로우 구성부(34)는, 자원 관리부(20)에서 관리하는 자원을 기반으로, 프론트 엔드부(10)를 통해 편집부(5)로부터 수신한 작업 구조(워크플로우 구조)와 작업 명세(워크플로우 명세)에 대응하는 속성명세 컴퍼넌트와 엔진 컴퍼넌트를 바인딩하는 과정을 통해 일련의 엔진 컴퍼넌트를 구성하고, 그 일련의 엔진 컴퍼넌트를 기반으로 하는 워크플로우 실행 플랫폼을 구성한다.

상기 엔진 컴퍼넌트와 바인딩되는 속성명세 컴퍼넌트는, 예를 들면, 구글의 Protobuf 메세지 객체, 스칼라의 Case Class, 자바의 Property 객체 등을 포함한다.

워크플로우 구성부(34)는 워크플로우를 구성하는 엔진 컴퍼넌트와 이 엔진 컴퍼넌트의 특성을 결정짓는 파라미터들을 정의한 속성명세 컴퍼넌트를 바인딩하여 생성한 엔진 컴퍼넌트들의 인스턴스를 엔진 컨테이너에 바인딩함으로써 워크플로우를 실행하기 위한 일련의 엔진 인스턴스들이 포함되는 워크플로우 실행 인스턴스부(52)를 동적으로 구성한다.

하나의 워크플로우를 실행하기 위해 생성된 엔진은 하나의 독립된 프로그램 패키지로서 네트워크로 연결된 다른 컴퓨팅 장치에 배포되고 실행된다.

로그 관리부(36)는 워크플로우를 구성하는 엔진의 실행에 따라 생성되는 로그 정보들을 관리하고, 이를 요청자에게 제공한다.

시스템 제어부(40)는 시스템 구성부(30)가 생성한 엔진 인스턴스(엔진)들을 구동하고, 또한 구동된 엔진 인스턴스(엔진)들을 종료시키는 역할을 수행한다. 즉, 시스템 제어부(40)가 워크플로우 실행 인스턴스부(52)에 워크플로우 실행을 요청하면, 워크플로우가 실행된다.

또한 시스템 제어부(40)는 특정 도메인에서 실행되도록 생성된 특정 엔진과 다른 특정 도메인에서 실행되도록 생성된 엔진이 서로 파이프라인 방식으로 실행되도록 제어할 수 있다. 이러한 엔진 구성에 대해서 아래에서 상세히 설명한다.

응용부(50)는, 워크플로우 실행 인스턴스부(52), 응용 저장소(54) 및 응용 접근 제어부(56)를 포함한다.

워크플로우 실행 인스턴스부(52)는 편집부(5)를 통해 정의된 워크플로우 사양(스펙)을 실행하기 위해 생성된 인스턴스들을 포함하도록 구성된다.

응용 저장소(54)는 워크플로우 상에서 수집 또는 가공된 데이터를 저장하기 위한 서비스를 제공한다. 이때, 응용 저장소부(54)는 특정 도메인 내에 있거나 외부에 있을 수 있다.

응용 접근 제어부(56)는 서로 다른 도메인의 워크플로우를 각각 구성하는 엔진들이 응용저장소(54)에 접근하는 것을 제어한다.

본 발명에 따른 엔진 프레임워크(100)는, 응용 저장소(54)와 응용 접근 제어부(56)를 이용하여 하나의 도메인에서 구성된 워크플로우의 구성과 절차를 확장함으로써, 서로 다른 공간 도메인, 서로 다른 업무 도메인 또는 서로 다른 목적 도메인에 공통으로 적용할 수 있는 크로스도메인 확장형 워크플로우를 구성할 수 있다. 이러한 응용 저장소(54)와 응용 접근 제어부(56)를 이용한 크로스도메인 확장 워크플로우 구성의 예는 아래에서 상세히 설명한다.

또한, 본 발명에 따른 워크플로우 엔진 프레임워크(100)는, 코어노드, 클라우드와 같은 하나 이상의 계층노드, 동일 계층의 다수의 엣지노드, 또는 코어 노드로 구성된 그룹내 노드들이 협력하여 하나의 목적을 달성하기 위한 워크플로우의 구성 및 실행 방법을 제공한다.

또한, 본 발명에 따른 워크플로우 엔진 프레임워크(100)는 주기적 기계학습 모델 튜닝과 서빙모델 업데이트 등과 같은 적응적 지능서비스 워크플로우 실행을 달성하기 위한 워크플로우를 구성하고 실행할 수 있다.

또한, 본 발명에 따른 워크플로우 엔진 프레임워크(100)는 하나 이상의 API를 연결하여 복합 API를 생성하기 위한 서비스 파이프라인용 워크플로우를 구성하고 실행할 수 있다.

이하, 본 발명의 일 실시 예에 따른 크로스도메인 확장형 워크플로우를 구성하기 위한 엔진 구성(엔진 컨테이너 구성)에 대해 설명하기로 한다.

도 3은 본 발명의 일 실시 예에 따른 크로스도메인 확장형 워크플로우를 구성하기 위한 엔진의 구성도이다.

도 3을 참조하면, 실시 예에 따른 크로스도메인 확장형 워크플로우를 구성하기 위해, 도 1에 도시된 응용 저장소(54)와 응용 접근 제어부(56)가 이용된다.

제1 엔진(60)은 도메인 #1의 제1 워크플로우를 구성(실행)하고, 제2 엔진(70)은 도메인 #2의 제2 워크플로우를 구성(실행)한다.

제1 엔진(60)은 제어기(controller)(61), 입력기(reader)(62), 다수의 단위 처리기(unit operator)(63, 64 및 65), 실행기(runner)(66) 및 출력기(writer)(67)를 포함하도록 구성된다. 제2 엔진(70)은 및 제어기(71), 입력기(72), 다수의 단위 처리기(73, 74 및 75), 실행기(76) 및 출력기(77)를 포함하도록 구성된다.

입력기(reader)(62, 72)는 제어기(61)의 제어에 따라 데이터 출발지(data source)로부터 데이터를 읽어오는 기능을 갖는다. 여기서, 데이터 출발지는, 예를 들면, 인메모리 버퍼/캐시, 파일시스템, 메세징 시스템, 데이터베이스, 네트워크 등의 다양한 논리적 드라이버 개념의 소스일 수 있다.

출력기(writer)(67, 77)는 인메모리 버퍼, 캐시 메모리, 파일시스템, 메세징 시스템, 데이터베이스, 네트워크드라이버 중의 어느 하나의 타입의 데이터 종착지(도시하지 않음)에 데이터를 쓰는 기능을 갖는다.

다수의 단위 처리기(63, 64 및 65/73, 74 및 75)는 종속적으로 연결되어, 입력기(62)가 데이터 저장소로부터 읽어온 데이터를 파이프라닝 방식으로 처리한다. 여기서, 각 단위 처리기에 수행되는 데이터 처리는, 예를 들면, 데이터의 정제, 통합, 축소 및/또는 변환 처리 등을 포함한다. 정제, 통합, 축소 및 변환과 같은 데이터 처리 과정은 데이터 마이닝 기술에서 자세히 소개하고 있으며, 이에 대한 설명은 공지 기술로 대신한다.

실행기(66, 76)는 데이터 처리에 필요한 모든 프로그램이나 외부 플랫폼/프레임워크들일 수 있다. 실행기(66 또는 76)는 , 예를 들면, 빅데이터 처리를 위한 Spark, 딥러닝 분석을 위한 Caffe, Tensorflow와 같은 딥러닝 플랫폼, Jena와 같은 지식 처리 엔진 중 하나와 연동하거나 이를 실행하기 위한 커넥터, REST 서버 또는 세션 관리기 등일 수 있다.

제어기(61, 71)는 입력기(62 또는 72), 다수의 단위 처리기(63, 64 및 65 또는 73, 74 및 75), 실행기(66 또는 76), 출력기(67 또는 77)을 제어한다.

제어기(61 또는 71)는, 도 3에 도시된 바와 같이, 각 엔진이 입력기(62 또는 72), 다수의 단위 처리기(63, 64 및 65 또는 73, 74 및 75), 실행기(66 또는 76), 출력기(67 또는 77)로 구성된 경우, 파이프라이닝 방식에 따라 각 구성에서 처리한 데이터를 다음 구성으로 전달하는 순차 처리 방식, 각 구성에서 동시에 데이터를 처리하는 동시 처리 방식, 순차 처리 방식과 동시 처리 방식을 결합한 방식 등으로, 상기 구성들을 제어할 수 있다.

제1 엔진(60)은 입력기(62)를 통해 데이터 출발지(Data source)로부터 읽어온 데이터를 처리하고, 그 처리한 데이터를 출력기(67)를 통해 응용 저장소(54)에 출력하는 제1 워크플로우를 수행한다. 이때 출력기(67)는 응용 저장소(54)에 접근하기 위한 접근 권한과 수단을 갖는다.

출력기(67)는 인증을 통해 응용 저장소(54)에 접근할 수 있는 접근 권한(access rights)을 할당 받을 수 있으며, 그 접근 권한을 할당받기 위해, 출력기(67)는, 예를 들면, OAuth(Open Authentication, 개방 인증)와 같은 인증 방식을 기반으로 응용 저장소(54)에 API를 통해 접근할 수 있는 토큰을 활용할 수 있다.

제2 엔진(70)의 입력기(72)는, 제1 엔진(60)의 출력기(67)와 마찬가지로, 토큰과 같은 접근권한을 가지며, 이러한 접근권한을 기반으로 응용 저장소(54)에 접근할 수 있다.

제2 엔진(70)의 입력기(72)는 응용 저장소(54)로부터 제1 엔진(60)에 의해 처리된 데이터를 읽어오고, 제2 엔진(70)의 다수의 단위 처리기(73, 74 및 75)는 제1 엔진(60)에 의해 처리된 데이터를 파이프라닝 방식으로 데이터 처리 과정을 수행하여, 그 처리 결과를 출력기(77)를 통해 데이터 종착지(Data destination)로 출력하는 제2 워크플로우를 실행한다.

응용 접근 제어부(56)는 제1 엔진(60 또는 출력기(67))과 제2 엔진(70 또는 입력기(72))에 대한 인증 과정을 수행하고, 그 인증 결과에 따라, 제1 엔진(60 또는 출력기(67))과 제2 엔진(70 또는 입력기(72))에게 응용 저장소(54)에 대한 접근 권한을 할당하는 역할을 수행한다.

이처럼 본 발명의 실시 예에서는 크로스도메인 확장형 워크플로우를 구성하기 위해, 도메인 #1의 제1 워크플로우를 구성하는 제1 엔진(60)과 도메인 #2의 제2 워크플로우를 구성하는 제2 엔진(70)이 응용 저장소(도 1의 54)를 매개로 유기적으로 결합됨으로써, 서로 다른 공간 도메인들, 서로 다른 업무 도메인들 및/또는 서로 다른 목적 도메인들 간의 융합이 가능한 워크플로우의 실행이 가능하다.

이하, 본 발명의 다른 실시 예에 따른 파일 시스템 기반으로 크로스도메인 확장형 워크플로우를 구성하는 엔진(엔진 컨테이너) 구성에 대해 설명하기로 한다. 이해를 돕기 위해, 파일 시스템 기반으로 데이터의 이동, 복사, 삭제를 수행하는 단일 엔진 구성에 대해 설명하기로 한다.

도 4는 본 발명의 실시 예에 따른 파일시스템 기반의 단일 엔진 구성을 도시한 도면이다.

도 4를 참조하면, 본 발명의 일 실시 예에 따른 파일시스템 기반의 엔진(또는 엔진 컨테이너)은 제어기(81), 입력기(82), 다수의 단위 처리기들(83, 84 및 85), 실행기(86) 및 출력기(87)를 포함하도록 구성된다.

입력기(82)는 제어기(81)의 제어에 따라 데이터 출발지(data source)로부터 파일 목록들을 읽어온다.

단위 처리기들(83, 84, 85)은 입력기(82)로부터 입력된 파일 목록에 대한 데이터 처리 과정을 파이프라인 방식으로 처리한 후, 그 처리 완료된 파일 목로들을 출력기(87)로 입력한다.

예를 들면, 단위 처리기(83)는, 입력기(82)로부터 입력된 파일 목록 중에서 데이터 종착지로 이동시키고자 하는 파일을 선정하도록 필터링하고, 단위 처리기(84)는 단위 처리기(83)에 의해 필터링된 파일의 파일명을 새로운 파일명으로 변환하고, 단위 처리기(85)는 단위 처리기들(83, 84)에 의해 처리된 파일 목록에 포함된 파일들의 서로 다른 디렉토리 경로들을 동일한 하나의 디렉토리 경로로 변경한다.

출력기(87)는 단위 처리기들(83, 84 및 85)에 의해 처리된 파일 목록과 그 파일 목록에 해당하는 파일들을 정의된 이동 경로에 따라 데이터 출발지로부터 데이터 종착지(data destination)로 이동 또는 복사하는 기능을 갖도록 정의될 수 있다.

또한, 출력기(87)는 단위 처리기들(83, 84 및 85)에 의해 처리된 파일 목록과 그 파일 목록에 해당하는 파일들을 데이터 출발지로부터 데이터 종착지(data destination)로 이동 또는 복사하지 않고, 삭제하는 기능을 갖도록 정의될 수 있다.

도 5는 도 4에 도시한 파일시스템 기반의 단일 엔진 구성을 이용하여 크로스도메인 확장형 워크플로우를 구성하기 위한 엔진의 구성도이고, 도 6은 도 5에 도시한 엔진 구성의 다른 예를 도시한 엔진의 구성도이다.

먼저, 도 5를 참조하면, 제1 및 제2 엔진(90, 110)은 도메인 #1의 제1 워크플로우를 구성(실행 또는 수행)하고, 제3 엔진(120)은 도메인 #1과 다른 물리적 공간을 정의하는 도메인 #2의 제2 워크플로우를 구성(실행 또는 수행)한다. 이때, 응용 저장소(54) 와 응용 접근 제어부(56)는 도메인 #2에서 실행된다.

제1 내지 제3 엔진(90, 110, 120) 각각은 제어기(91, 111, 121), 입력기(92, 112, 122), 단위 처리기(93, 113, 123), 실행기(94, 114, 124) 및 출력기(95)를 포함하도록 구성된다.

제1 내지 제3 엔진(90, 110, 120) 중 적어도 하나는 도 4에 도시한 파일 시스템 기반의 단일 엔진으로 구성된다. 즉, 제1 내지 제3 엔진(90, 110, 120) 모두가 파일 시스템 기반의 단일 엔진으로 구성되거나 일부만 파일 시스템 기반의 단일 엔진으로 구성될 수 있다. 물론, 제1 내지 제3 엔진(90, 110, 120) 모두 도 3에 도시에 도시한 단일 엔진(60 또는 70)으로 구성될 수도 있다.

도 5의 엔진 구성에서는 제2 엔진(110)이 파일 시스템 기반의 단일 엔진으로 구성되고, 제1 및 3 엔진(90 및 120)가 도 3에 도시에 도시한 단일 엔진(60 또는 70)('데이터 기반의 단일 엔진')으로 구성된다.

제2 엔진(110)에 포함된 구성들에 대한 설명은 도 4의 파일 시스템 기반의 단일 엔진에 포함된 각 구성에 대한 설명으로 대신하고, 제1 및 제3 엔진(90 및 120) 각각에 포함된 구성들에 대한 설명은 도 3에 도시한 데이터 기반의 단일 엔진(60 또는 70)에 포함된 각 구성에 대한 설명으로 대신한다.

또한, 도 5에서 도 3 및 4와는 다르게, 각 엔진이 하나의 단위 처리기(93, 113, 123)만을 포함하고 있으나, 이는 도면의 간략화를 위함이지, 본 발명을 한정하고자 하는 의도는 아니다.

이하, 도메인 #1의 제1 워크플로우와 도메인 #2의 제2 워크플로우의 융합을 위해, 도메인 #1의 제1 워크플로우에 대한 처리 결과를 도메인 #2로 전달하는 방법에 대해 설명한다.

우선, 도메인 #1의 제1 엔진(90)이 데이터 출발지(A)로부터 읽어온 데이터(파일 목록 및 파일)에 대해 데이터 처리과정을 수행하고, 그 처리 완료된 데이터(파일 목록 및 파일)를 중간 데이터 종착지(B)로 출력한다.

이어, 제2 엔진(110)이 중간 데이터 종착지(B)로부터 파일 목록들을 읽어오고, 읽어온 파일 목록들 중에서 도메인 #2에 전달하고자 하는 파일 목록을 추출(필터링)하여, 제2 도메인에서 실행되는 응용 저장소(54)에 출력한다.

이때 도메인 #2의 응용 접근 제어부(56)는 도메인 #1에서 실행되는 제2 엔진(100)의 출력기(115)가 응용 저장소(54)에 접근할 수 있는 접근 권한이 있는지 확인하고, 접근 권한이 있는 것으로 검증되면, 제2 엔진(110)의 출력기(115)는 응용 저장소(54)에 접근하여, 단위 처리기(113)에 의해 추출(필터링)된 파일 목록(이하, 제1 워크플로우의 처리 결과)을 응용 저장소(54)로 출력한다.

그러면, 도메인 #2의 제3 엔진(120)은 응용 저장소(54)로부터 제2 엔진에 의해 처리 완료된 제1 워크플로우의 처리 결과를 읽어오고, 그 읽어온 제1 워크플로우의 처리 결과에 대해 정의된 데이터 처리 과정을 수행하여, 최종 데이터 종착지(C)로 출력한다.

다음으로, 도 6의 엔진 구성은 응용 저장소(54)와 응용 접근 제어부(56)가 도메인 #1에 실행되는 점에서 도 5의 엔진 구성과 가장 큰 차이점이 있다. 이하의 설명에서는 제1 엔진(90)의 출력기와 제2 엔진(110)의 입력기(112)가 응용 저장소(54)에 대한 접근 권한이 있는 것으로 가정한다.

도 6을 참조하면, 도메인 #1의 제1 엔진(90)은 데이터 출발지(A)로부터 읽어온 데이터(파일 목록 및 파일)에 대해 데이터 처리 과정을 수행한 후, 그 처리 결과를 도메인 #1의 응용 저장소(54)에 접근하여, 응용 저장소(54)로 출력한다.

이후, 도메인 #2의 제2 엔진(110)은 입력기(112)를 통해 도메인 #1의 응용 저장소(54)에 접근하여, 응용 저장소(54)로부터 제1 엔진(90)에 의해 처리된 처리 결과를 읽어온다.

이후, 제2 엔진(110)은 응용 저장소(54)로부터 읽어온 그 처리 결과에 포함된 파일 목록들 중에서 필요한 파일 목록을 추출(필터링)한 후, 추출된 파일 목록과 파일을 중간 데이터 종착지(B)로 이동시키거나 복사한다.

이후, 제3 엔진(120)은 입력기(122)를 통해 중간 데이터 종착지(B)로 이동 또는 복사된 데이터(파일 목록과 파일)를 읽어온 후, 단위 처리기(123)를 통해 정해진 방식으로 데이터 치리 과정을 수행한 후, 출력기(125)를 통해 최종 데이터 종착지(C)로 출력한다.

도 7은 본 발명의 실시 예에 따른 크로스도메인 확장형 워크플로우 기반의 협력형 지능 서비스를 제공하는 방법을 설명하기 위한 도면이다.

도 7을 참조하면, 본 발명의 실시 예에 따른 협력형 지능 서비스는, 도 3 내지 도 6에서 설명한 엔진 구성을 기반으로, 엣지 도메인과 코어 도메인이 서로 협력하여 하나의 목적을 달성하기 위한 크로스도메인 확장형 워크플로우를 구성하고, 실행한다.

협력형 지능 서비스를 제공하기 위해, 엣지 도메인 #1의 워크플로우, 엣지 도메인 #2의 워크플로우 및 코어 도메인의 워크플로우를 구성하고, 실행할 수 있는 워크플로우 엔진 프레임워크가 설치 및 운영되는 시스템 환경이 가정된다.

엣지 도메인 #1의 제1 엣지 노드(170)는 데이터 출발지(160)로부터 데이터를 수집하고 처리하기 위한 워크플로우 #1을 실행한다. 여기서, 제1 엣지 노드(170)는 제1 엣지 노드(170)에서 엣지 도메인 #의 제1 워크플로우를 실행하는 엔진으로 지칭될 수 있다.

워크플로우 #1은 데이터 출발지(160)로부터 수집된 데이터를 처리하는 엔진과 그 처리한 결과(데이터 파일)를 코어 도메인의 코어 노드(190)와 공유하기 위해 공유 저장소(180, 응용 저장소)로 이동 또는 복사하는 파일 시스템 기반의 엔진으로 구성된다.

코어 도메인의 코어 노드(190)는 공유 저장소(180)로부터 제1 엣지 노드(170)에 의한 처리 결과(데이터 파일)를 훈련 데이터로 이용하여 학습 모델에 대한 파인 튜닝을 수행하는 워크플로우 #2를 실행한다. 여기서, 코어 노드(190)는 코어 노드(190)에서 코어 도메인의 워크플로우#2를 실행하는 엔진으로 지칭될 수 있다.

워크플로우 #2는 공유 저장소(180)로부터 워크플로우 #1의 처리 결과(데이터 파일)를 훈련 데이터로서 읽어오는 엔진, 읽어온 훈련 데이터(데이터 파일)을 이용하여 파인 튜닝을 위한 학습을 수행하는 엔진, 그 학습 결과에 따라 생성된(업데이트된) 신규 버전의 학습 모델을 공유 저장소(200)로 이동시키는 엔진으로 구성된다.

엣지 도메인 #3의 제2 엣지 노드(210)는 공유 저장소(200)로부터 로딩된 신규버전의 학습 모델을 이용하여 예측 서비스를 수행하는 워크플로우 #3을 실행한다. 여기서, 제2 엣지 노드(210)는 엣지 도메인 #3의 워크플로우 #3을 실행하는 엔진으로 지칭될 수 있다.

워크플로우 #3은 신규 버전의 학습 모델을 공유 저장소(200)로부터 제2 엣지 노드로 이동시키는 엔진, 공유 저장소(200)로부터 이동된 신규 버전의 학습 모델을 이용하여 예측 서비스를 제공하기 위한 서빙을 수행하는 서빙 엔진으로 구성된다.

이처럼, 엣지 노드와 코어 노드가 서로 협력하여 워크플로우를 수행함으로써, 협력형 지능 서비스를 제공하는 것이 가능하다.

도 8은 본 발명의 일 실시 예에 따른 서로 다른 업무 및 목적 도메인들에서 제공하는 서비스들을 융합한 융합 지능 서비스를 정의하기 위한 엔진(엔진 컨테이너, 엔진 컨테이너 시스템 또는 엔진 컨테이너 장치)의 구성도이다.

도 8을 참조하면, 서로 다른 업무 및 목적 도메인들에서 제공하는 서비스들을 융합한 융합 지능 서비스를 정의하기 위한 엔진(300)은 제어기(301), 다수의 오퍼레이터(302~306), 실행기(307)를 포함하도록 구성되며, 이러한 구성 요소들은 도 3 및 4를 참조하여 설명한 구성들과 유사하다.

다만, 도 8의 엔진(300)은 워크플로우 서비스에 있어서 서비스 실행을 서빙하는 기능을 위하여 구성되며, 이러한 점에서 서빙 엔진(serving engine)으로 불릴 수 있다.

제어기(301)는 다수의 오퍼레이터(302~306) 및 실행기 (307)의 동작을 제어한다.

다수의 오퍼레이터(operator)(302~306)는 다수의 REST(Representational State Transfer) API(Application Programming Interface)(410~430) 및 지식 베이스(440)와 각각 연동한다. 각 오퍼레이터는 도 3 내지 6에 도시한 단위 처리기와 유사한 구성으로 볼 수 있다. 이때, 다수의 오퍼레이터(302~306)는 서로 다른 목적 도메인에 따라 서로 다른 서비스를 제공하기 위한 데이터 처리를 수행하는 것일 수 있다.

실행기(307)는 REST(Representational State Transfer) 서버이거나 REST 서버와 연동하는 것일 수 있으며, 클라이언트(400)의 요청에 따라 오퍼레이터들(302~306)을 순차적으로 호출한다.

각 오퍼레이터(Operator)는 실행기(307)의 호출 시에, 실행기(307)로부터 전달된 URL(Uniform Resource Locator) 정보 또는 자신이 알고 있는 URL 정보를 이용하여 해당(대응하는) REST API를 호출하고, 호출한 REST API를 통해 제공된 데이터를 처리하여 다음 오퍼레이터(Operator)로 전달하는 파이프라인 방식으로 동작한다.

최종 오퍼레이터(306)의 처리 결과는 실행기(307)를 통해 클라이언트(400)로 다시 반환된다.

도 9는 본 발명의 다른 실시 예에 따른 서로 다른 업무 및 목적 도메인들에서 제공하는 서비스들을 융합한 융합 지능 서비스를 정의하기 위한 엔진(엔진 컨테이너)의 구성도이다.

도 9를 참조하면, 본 발명의 다른 실시 예에 따른 엔진(300')은 입력기(reader)(309)와 출력기(writer)(310)를 더 포함하고 있는 점을 제외하면, 도 8에 도시한 엔진의 구성과 동일하다.

엔진(300')은, 예를 들면, 메시지 큐(Message Queue), Kafka 등으로부터 데이터를 읽어오는 입력기(309)와, 그 읽어온 데이터를 온톨로지 기반 추론 방식 (ontology-based reasoning)으로 데이터를 수행하는 오퍼레이터(302~306)들과, 그 추론 결과를 REST 인터페이스를 통해서 서비스하는 실행기(307) 및 상기 추론 결과를 메시지 큐(Message Queue), Kafka 등으로 출력하는 출력기(310)를 포함하도록 구성됨으로써, 융합 지능 서비스를 제공할 수 있다.

도 10 내지 14는 도 8 및 9에서 도시한 융합 지능 서비스를 위한 엔진의 내부 처리 절차를 설명하기 위한 도면들이다.

먼저, 도 10의 융합 지능 서비스를 위한 엔진의 내부 처리 절차는 오퍼레이터들의 처리 결과들이 서로 영향을 미치지 않는 독립적인 경우에서 수행되는 내부 처리 절차이다.

먼저, REST 서버 내의 실행기(307)가 클라이언트(400)로부터의 융합 지능 서비스 요청에 따라 첫번째 오퍼레이터(302)를 호출하고(②), 호출된 첫번째 오퍼레이터(302)는 대응하는 RESTful API(450)(또는 외부 서버)에게 질의 데이터를 전달하고(③), 그에 대한 응답 데이터(④)를 RESTful API(450)로부터 수신한다.

첫번째 오퍼레이터(302)의 처리 결과는 질의에 사용되는 입력 파라메터가 기록되는 입력 필드(Input field), 데이터가 기록되는 데이터 필드(Data field), 질의 주소를 가리키는 라우팅 정보가 기록되는 라우트 필드(Route field) 및 상기 응답 데이터(④)가 기록되는 출력 필드(Output field)로 이루어진 데이터 포맷으로 구성된다.

이러한 필드의 배열 순서는 오퍼레이터 별로 상이할 수 있으며, 상기 입력 필드, 데이터 필드 및 라우트 필드에 기록되는 정보들은 상기 질의 데이터의 주요 정보로 활용될 수 있다.

첫번째 오퍼레이터(302)가 질의/응답 절차를 완료하면, 두 번째 오퍼레이터(303)가 대응하는 RESTful API(460)에게 질의 데이터(⑤)를 전달하고, 그에 대한 응답 데이터(⑥)를 RESTful API(460)로부터 수신하고, 수신한 응답 데이터가 반영된 처리 결과를 출력한다.

두번째 오퍼레이터가 질의/응답 절차를 완료하면, 세 번째 오퍼레이터(304)가 RESTful API(470)에게 질의 데이터(⑦)를 전달하고, 그에 대한 응답 데이터(⑧)를 RESTful API(470)로부터 수신하고, 수신한 응답 데이터가 반영된 처리 결과를 출력한다.

모든 오퍼레이터들(302, 303 및 304)의 질의/응답 절차가 완료되면, 실행기(307)는 각 오퍼레이터가 출력한 처리 결과들를 취합하여, 이들을 클라이언트(400)에게 반환한다(⑨).

도 11의 융합 지능 서비스를 제공하기 위한 엔진의 내부 처리 절차는 각 오퍼레이터(Operator)가 이전 오퍼레이터의 처리 결과를 자신의 질의에 반영하는 체이닝(chaining) 방식을 지원하는 점에서 도 10에 도시한 내부 처리 절차와 차이가 있다.

도 11을 참조하면, 클라이언트(400)의 서비스 요청(①)에 따라 실행기(307)가 호출한 첫 번째 오퍼레이터(302)는 입력 파라메터, 라우팅 정보, 데이터를 질의 데이터로 구성하여, 대응하는 RESTful API(450)로 전달한다(③).

첫 번째 오퍼레이터(302)는 상기 질의 데이터에 대한 응답 데이터를 수신하여, 상기 질의 데이터의 출력 필드에 상기 응답 데이터를 기록하여, 상기 출력 필드를 업데이트 한다.

출력 필드의 업데이트가 완료되면, 첫 번째 오퍼레이터(302)는 입력 파라메터, 라우팅 정보, 및 응답 데이터로 구성된 처리 결과를 두 번째 오퍼레이터(303)로 출력한다.

두 번째 오퍼레이터(303)는 첫번째 오퍼레이터(303)로부터 출력된 처리 결과(입력 파라메터, 라우팅 정보, 데이터 및 RESTful API(450)의 응답 데이터)를 이용하여 자신(303)의 질의 데이터를 업데이트한다. 즉, 두 번째 오퍼레이터(303)의 질의 데이터는 첫 번째 오퍼레이터(302)의 처리 결과를 포함하도록 업데이트된 것일 수 있다.

이후, 두 번째 오퍼레이터(303)는 업데이트된 자신의 질의 데이터(⑤)를 대응하는 RESTful API(460)(또는 외부 서버)로 전달하고, RESTful API(460)로부터 업데이트된 질의 데이터(⑤)에 대한 응답 데이터(⑥)를 수신하고, 그 응답 데이터(⑥)로 출력 필드를 업데이트한다.

출력 필드의 업데이트가 완료되면, 두 번째 오퍼레이터(303)는 처리 결과를 세 번째 오퍼레이터(304)로 출력한다.

유사하게, 세번째 오퍼레이터(304)는 두번째 오퍼레이터(303)로부터 입력된 처리 결과에 포함된 질의 데이터를 이용하여 자신의 질의 데이터를 업데이트하고, 업데이트된 질의 데이터(⑦)를 해당 RESTful API(470)로 전달하고, 상기 업데이트된 질의 데이터에 대한 응답 데이터(⑧)를 수신하고, 그 응답 데이터로 출력 필드를 업데이트를 한다.

출력 필드의 업데이트가 완료되면, 세 번째 오퍼레이터(304)는 처리 결과를 실행기(307)로 전달하고, 실행기(307)는 세 번째 오퍼레이터(304)로부터 전달된 최종 결과(⑨)를 클라이언트에게 반환한다.

도 12의 융합 지능 서비스를 제공하기 위한 엔진의 내부 처리 절차는 데이터 필드를 읽어오는 입력기(Reader)와 처리된 데이터 필드를 출력하는 출력기(Writer)를 더 포함하는 경우에서 수행되는 내부 처리 절치이다.

클라이언트(400)는 질의 데이터 포함되는 실제 데이터를 제외한 나머지 데이터(Input/Route)만을 포함하는 서비스 요청 메시지를 실행기(307)로 전달한다(①).

실행기(307)는 서비스 요청 메시지에 포함된 데이터(Input/Route)를 입력기(309)로 출력한다.

입력기(309, Reader)는 데이터 출발지(12)로부터 데이터를 읽어와 데이터 필드를 업데이트 한다. 이 때 입력기(309, Reader)가 데이터 출발지(12)로부터 읽어오는 데이터는 각각의 Operator 별로 Data를 명시하고 있는 배열 형태를 가질 수 있다.

다음으로 오퍼레이터(303)는 입력기(309, Reader)로부터 읽어온 데이터를 포함하는 질의 데이터를 생성하여 RESTful API(460)로 전달하고(⑤), 질의 데이터에 대한 응답 데이터를 RESTful API(460)로부터 수신한다(⑥).

오퍼레이터(303)의 질의 및 응답 절차가 완료된 후, 오퍼레이터(303)는 질의 데이터와 응답 데이터를 포함하는 처리 결과를 출력기(310)로 출력한다(⑦).

출력기(310)는 오퍼레이터(303)로부터 수신한 처리 결과의 일부 또는 전체를 데이터 종착지(13)로 출력한다.

마지막으로 실행기(307, Runner)는 출력기(310)로부터 수신한 오퍼레이터(303)의 처리 결과를 클라이언트(400)에 전달한다.

도 13의 융합 지능 서비스를 제공하기 위한 엔진이 내부 처리 절차는 마지막 오퍼레이터(304)가 출력을 집계(aggregation)하는 기능을 수행하는 경우에서의 내부 처리 절차이다.

클라이언트의 요청(①)에 따라, 실행기(307)는 오퍼레이터들(302, 303)를 순차적으로 호출하고(②), 순차적으로 호출된 오퍼레이터들(302, 303)은 대응하는 RESTful API(450, 460)들로 질의 데이터를 각각 전달한다(③, ⑤).

각 오퍼레이터는 질의 데이터에 대한 응답 데이터를 수신하고(④, ⑥), 그 응답 데이터를 이용하여 출력 필드에 업데이트한다.

출력 집계 기능을 갖는 마지막 오퍼레이터(304)는 Property로 정의된 집계 방법(평균, 합계, And, Or, Min, Max, Percentile 등)을 이용하여 이전 오퍼레이터들(302, 303)의 처리 결과에 포함된 데이터들(450과 460의 응답 데이터들(④, ⑥))를 집계하고, 그 집계한 결과로 자신(304)의 처리 결과에 포함된 출력 필드를 업데이트한다.

실행기(307)는 마지막 오퍼레이터(304)에 의해 집계된 처리 결과를 클라이언트(400)에게 반환한다(⑨).

도 14의 융합 지능 서비스를 제공하기 위한 엔진의 내부 처리 절차는, 질의 주소를 가리키는 Url 정보를 포함하는 룩업 테이블을 갖는 오퍼레이터들(303)를 포함하는 경우에서의 내부 처리 절차이다.

먼저, 클라이언트의 요청(①)에 따라, 실행기(307)에 의해 호출된 첫번째 오퍼레이터(302)가 질의 데이터를 대응하는 API(450)(또는 외부 서버)로 전달하고, API(450)(또는 외부 서버)로 그 질의 데이터에 대한 응답 데이터(④)를 포함하도록 처리 결과를 구성하여 두번째 오퍼레이터(303)로 전달한다.

두 번째 오퍼레이터(303)는 Url에 대한 룩업 테이블을 가지며, 첫번째 오퍼레이터(302)의 처리 결과를 구성하는 출력 필드에 기록된 데이터(450의 응답 데이터(④))를 인덱스로 이용하여, 상기 출력 필드에 기록된 데이터(450의 응답 데이터(④))에 매핑되는 Url값(또는 Url 정보)을 룩업 테이블로부터 추출한다.

이후, 두 번째 오퍼레이터(303)는 상기 룩업 테이블로부터 추출된 Url값(또는 Url 정보)을 포함하도록 처리 결과를 구성하여 세 번째 오퍼레이터(304)로 전달한다. 여기서, 두 번째 오퍼레이터(303)가 룩업 테이블을 이용하여 추출한 Url값은 세 번째 오퍼레이터(304)의 라우팅 정보를 업데이트하기 위한 용도로 사용된다. 즉, 세 번째 오퍼레이터(304)는 두 번째 오퍼레이터(303)가 추출한 Url값이 가리키는 외부 서버(460, 470)로 자신(304)의 질의 데이터를 전달한다.

마지막 오퍼레이터(304)는 상기 추출한 Url에 의해 업데이트된 라우팅 정보에 따른 질의 주소에 해당하는 API(460, 470)로 질의 데이터를 전달하고, 그에 대한 응답 데이터를 수신하고, 응답 데이터를 포함하는 처리 결과를 실행기(307)로 전달한다.

실행기(307)는 마지막 오퍼레이터(304)로부터 전달된 처리 결과를 클라이언트(400)로 반환한다(⑨).

도 15는 도 13에 도시한 집계 기능을 갖는 오퍼레이터를 포함하는 엔진 구성을 이용하여 배관 누출(pipe leakage) 탐지와 관련된 워크플로우 서비스 시나리오를 설명하기 위한 도면이다.

도 15에 도시한 누출 탐지와 관련된 워크플로우 서비스 시나리오는 하나 이상의 지능 API를 앙상블 방식으로 구성하여 응답을 주는 엔진으로 구성된다.

서비스 클라이언트(500)는 배관의 음향신호를 수집하여 누출여부를 예측하는 API를 호출하고, 호출된 API를 서비스하는 실행기(600)는 오퍼레이터들(610, 620, 630)을 순차적으로 호출한다.

실행기(600)에 의해 호출된 오퍼레이터들(610, 620, 630) 각각은 배관 누출과 관련된 질의 데이터를 구성하여 각자의 외부 서버(710, 720, 730)로 전달한다.

외부 서버(610', 620', 630')들은 누출 탐지 알고리즘과 같은 예측 모델을 이용하여 누출 여부를 판별하고, 그 판별 결과를 응답 데이터를 구성하여 각자의 오퍼레이터들(610, 620, 630)로 전달한다.

마지막 오퍼레이터(640)는 각 오퍼레이터(610, 620, 630)의 처리 결과를 집계하고, 그 집계한 결과를 이용하여 배관 누출 여부를 최종적으로 판별하고, 그 최종 판별 결과를 실행기(600)를 통해 서비스 클라이언트(500)에 반환한다.

도 16은 도 14에 도시한 룩업 테이블을 갖는 오퍼레이터를 포함하도록 구성된 엔진 구성을 이용하여 대화 생성과 관련된 워크플로우 서비스 시나리오를 설명하기 위한 도면이다.

도 16을 참조하면, 도 16을 참조하면, 엔진 내의 첫번째 오퍼레이터(710)는 실행기(700)를 통해 클라이언트(500)로부터 문장을 수신하고, 그 수신한 문장의 토픽 분류를 요청하는 질의 데이터를 생성하여, 그 질의 데이터를 토픽(Topic) 추출을 위한 분류기 모델을 서비스하는 외부 서버(710')로 전달하고, 그 외부 서버(710')로부터 분류기 모델에 의해 추출된 토픽 정보를 포함하는 응답 데이터를 수신한다.

첫번째 오퍼레이터(710)는 외부 서버(710')로부터 수신한 응답 데이터를 포함하도록 처리 결과를 구성하여, 이를 두번째 오퍼레이터(720)로 전달한다.

두번째 오퍼레이터(720)는 첫번째 오퍼레이터(710)로부터 전달된 처리 결과에 포함된 분류 결과(토픽 정보)에 매핑되는 Url 주소를 룩업 테이블로부터 추출하고, 그 Url 주소를 포함하도록 처리 결과를 구성하여 마지막 오퍼레이터(730)로 전달한다.

마지막 오퍼레이터(730)는 두번째 오퍼레이터(720)의 처리 결과에 포함된 Url 주소를 이용하여 질의 데이터를 생성하고, 상기 Url 주소가 가리키는 외부 서버(720', 730')로 질의 데이터를 전달한다. 이때, 외부 서버(720', 730')는 응답 문장을 예측하는 대화 생성 모델을 서비스하는 것일 수 있다.

외부 서버(720', 730')는 상기 응답 문장을 응답 데이터로 구성하여 마지막 오퍼레이터(730)로 전달하고, 마지막 오퍼레이터(730)는 응답 데이터에 포함된 응답 문장 실행기(700)를 통해 서비스 클라이언트(500)에 반환한다.

이처럼 서비스 클라이언트(500)가 문장을 입력하면, 최초 오퍼레이터의 질의 결과인 Topic 분류 결과에 따른 문장 생성 API의 주소가 선택적으로 결정되어, 문장의 문맥에 맞는 응답문이 생성되고, 그 응답문이 서비스 클라이언트(500)로 반환된다.

도 17은 본 발명의 실시 예에 따른 융합 지능 서비스와 관련된 예측 모델을 주기적으로 업데이트 하기 위한 하나 이상의 워크플로우를 실행하고 제어하는 오케스트레이션 방법을 설명하기 위한 도면이다.

본 발명의 오케스트레이션 방법은, 시계열 데이터의 실시간 처리, 시계열 예측모델을 주기적으로 파인 튜닝(fine-tuning) 하여 서비스 중인 예측 모델을 업데이트하는 하나 이상의 워크플로우 파이프라인이 지속적으로, 순차적으로, 주기적으로 실행됨으로써, 지속적인 예측 서비스를 제공할 수 있다.

도 17을 참조하면, 실시간 데이터 처리(①)를 위한 워크플로우 #1이 구성된다. 실시간 스트림 방식의 프레임워크에서 실행된다.

워크플로우 #1은 데이터를 실시간으로 정제하기 위한 엔진, 엔진으로부터 전달된 정제된 데이터를 이용하여 학습용 데이터(훈련 데이터)를 만들기 위한 feature engineering을 수행하는 미니 배치(mini batch) 형식의 실시간 스트림 엔진 및 상기 학습용 데이터를 파일 스트림으로 생성하기 위한 시계열 스트림 파일 생성 엔진에 의해 구성된다.

실시간 추론 서빙(②)을 위한 워크플로우 #2는 워크플로우 #1의 실행에 의해 처리된 실시간 데이터를 스트림 방식으로 수신하여 예측을 위한 추론(inference)을 수행하는 엔진#1 및 엔진#1에 의한 예측 결과들의 정확도를 평가하기 위한 평가용 데이터셋을 구성하고, 그 평가용 데이터셋을 파일 스트림 형태로 생성하는 엔진#2로 구성된다.

엔진#2는 엔진#1에 의해 수행된 예측 결과들 중에서 특정 예측 결과들을 다양한 방식으로 선정하고, 그 선정된 특정 예측 결과들을 평가용 데이터셋으로 구성할 수 있다. 상기 엔진#1에 의해 추론된 결과는 클라이언트에게 전달되기 위해 스트림 전용 메세지 큐로 출력된다.

워크플로우 #3은 신규 데이터를 이용해 예측 모델을 주기적으로 fine-tuning 하는 워크플로우이다.

이러한 워크플로우 #3은 워크플로우 #1에 의해 생성된 실시간 스트리밍 파일의 목록으로부터 특정 기준 시간에 fine-tuning을 위한 시계열 데이터를 추출하는 엔진 #1, 시계열 데이터로부터 검증을 위한 예측 결과의 ground-truth값을 자동 매핑하는 엔진 #2, 모델 파라메터를 fine-tuning하기 위한 학습용 엔진 #3 그리고 학습을 위해 임시로 생성한 파일을 삭제하는 엔진 #4으로 구성된다.

워크플로우 #4는 워크플로우 #2의 엔진 #2에 의해 생성된 평가용 데이터셋을 이용하여 예측 서비스의 평가를 주기적으로 수행한다.

이러한 워크플로우 #4는 워크플로우 #2의 엔진 #2에 의해 생성된 평가용 데이터셋으로부터 특정 시점에서 예측 결과를 추출하는 엔진 #1, 평가용 데이터셋을 라벨링하여 획득한 라벨값과 상기 특정 시점에서 추출된 예측 결과를 비교하여 평가하는 엔진 #2, 상기 엔진 #2의 의한 평가 결과를 기반으로 예측 모델을 업데이트 여부를 결정하는 엔진 #3, 및 평가 완료 후에 상기 평가용 데이터셋을 삭제하는 엔진 #4로 구성된다.

이러한 오케스트레이션 방법은 실시간 예측을 위해, 워크플로우#1과 #2를 구동과 함께 실행되어 실시간 스트리밍 처리 파이프라인을 유지시킨다.

워크플로우#3과 #4는 특정 주기에 의해 구동되도록 하여 주기에 따라 수집한 데이터로부터 학습모델을 파인튜닝하고 최적의 성능을 내는지 여부를 주기적으로 평가하도록 한다.

본 발명에 따른 크로스도메인 확장형 워크플로우 엔진 프레임워크는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다.

예를 들어, 실시예 들에서 설명된 구성요소는, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPGA(field programmable gate array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다.

소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치, 또는 전송되는 신호 파(signal wave)에 영구적으로, 또는 일시적으로 구체화(embody)될 수 있다.

소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

이제까지 본 발명을 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양하게 변경 또는 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명을 위한 예시적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

Claims (10)

1. 프로세서를 포함하는 컴퓨팅 장치에 의해 실행되는 크로스도메인 확장형 워크플로우 엔진 프레임워크(이하, '워크플로우 엔진 프레임워크')에서 사용자에 의해 정의된 워크플로우 명세에 따라 생성된 엔진 컨테이너로서,
   상기 엔진은, 서로 다른 목적 도메인에서 제공하는 서로 다른 서비스들을 융합하기 위한 융합 지능 서비스를 제공하기 위해,
   다수의 REST(Representational State Transfer) API(Application Programming Interface)와 각각 연동하는 다수의 오퍼레이터;
   클라이언트의 요청에 따라, 상기 다수의 오퍼레이터를 순차적으로 호출하는 실행기; 및
   상기 다수의 오퍼레이터와 상기 실행기의 동작을 제어하는 제어기를 포함하고,
   각 오퍼레이터는,
   상기 실행기로부터 전달된 URL(Uniform Resource Locator) 정보를 이용하여 해당 REST API를 호출하고, 상기 호출한 해당 REST API를 통해 제공된 데이터를 처리하여 획득한 처리 결과를 다음 오퍼레이터로 전달하는 파이프라인 방식으로 동작하는 것을 특징으로 하는 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 정의된 엔진 컨테이너.
2. 제1항에서,
   상기 다수의 오퍼레이터 중에서 최종 오퍼레이터이 처리 결과는 상기 실행기를 통해 상기 클라이언트로 다시 반환되는 것인 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 정의된 엔진 컨테이너.
3. 제1항에서,
   상기 실행기는 REST(Representational State Transfer) 서버인 것인 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 정의된 엔진 컨테이너.
4. 제1항에서,
   입력기(reader) 및 출력기(writer)를 더 포함하고,
   상기 입력기는,
   메시지 큐(Message Queue)로부터 읽어온 데이터를 상기 파이프라이닝 방식으로 처리하는 다수의 오퍼레이터로 전달하고,
   상기 출력기는,
   상기 다수의 오퍼레이터가 상기 파이프라닝 방식으로 처리하여 획득한 처리 결과를 다른 메시지 큐로 출력하는 것인 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 정의된 엔진 컨테이너.
5. 제4항에서,
   상기 다수의 오퍼레이터는,
   상기 입력기로부터 전달된 데이터를 온톨로지 기반 추론 방식으로 처리하는 것인 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 정의된 엔진 컨테이너.
6. 제1항에서,
   상기 다수의 오퍼레이터들은 상기 실행기에 의해 순차적으로 호출되는 제1 오퍼레이터 및 제2 오퍼레이터를 포함하고,
   상기 제1 오퍼레이터는, 대응하는 제1 REST API에게 제1 질의 데이터를 전달하고, 상기 제1 질의 데이터에 대한 제1 응답 데이터를 상기 제1 REST API로부터 전달받은 후, 상기 제1 질의 데이터와 상기 제1 응답 데이터를 포함하도록 구성된 제1 처리 결과를 출력하고,
   상기 제2 오퍼레이터는, 대응하는 제2 REST API에게 제2 질의 데이터를 전달하고, 상기 제2 질의 데이터에 대한 제2 응답 데이터를 상기 제2 REST API로부터 전달받은 후, 상기 제2 질의 데이터와 상기 제2 응답 데이터를 포함하도록 구성된 제2 처리 결과를 출력하고,
   상기 실행기는, 상기 제1 및 제2 오퍼레이터로부터 전달된 상기 제1 및 제2 처리 결과를 클라이언트로 반환하는 것인 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 정의된 엔진 컨테이너.
7. 제6항에서,
   상기 제1 및 제2 처리 결과 각각은,
   질의 데이터에 사용되는 입력 파라메터가 기록되는 입력 필드(Input field), 데이터가 기록되는 데이터 필드(Data field), 질의 주소를 가리키는 라우팅 정보가 기록되는 라우트 필드(Route field) 및 응답 데이터가 기록되는 출력 필드(Output field)를 포함하는 데이터 포맷으로 구성된 것인 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 정의된 엔진 컨테이너.
8. 제1항에서,
   상기 다수의 오퍼레이터들은 상기 실행기에 의해 순차적으로 호출되는 제1 오퍼레이터 및 제2 오퍼레이터를 포함하고,
   상기 제1 오퍼레이터는, 대응하는 제1 REST API에게 제1 질의 데이터를 전달하고, 상기 제1 질의 데이터에 대한 제1 응답 데이터를 상기 제1 REST API로부터 전달받은 후, 상기 제1 질의 데이터와 상기 제1 응답 데이터를 포함하도록 구성된 제1 처리 결과를 상기 제2 오퍼레이터로 전달하고,
   상기 제2 오퍼레이터는, 상기 제1 처리 결과를 포함하도록 업데이트된 제2 질의 데이터를 대응하는 제2 REST API에게 전달하고, 상기 제2 질의 데이터에 대한 제2 응답 데이터를 상기 제2 REST API로부터 전달받은 후, 상기 제2 질의 데이터와 상기 제2 응답 데이터를 포함하도록 구성된 제2 처리 결과를 상기 실행기로 전달하고,
   상기 실행기는, 상기 제2 처리 결과를 최종 처리 결과로서 클라이언트로 반환하는 것인 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 정의된 엔진 컨테이너.
9. 제1항에서,
   상기 다수의 오퍼레이터들은 상기 실행기에 의해 순차적으로 호출되는 제1 오퍼레이터, 제2 오퍼레이터 및 제3 오퍼레이터를 포함하고,
   상기 제1 오퍼레이터는, 대응하는 제1 REST API에게 제1 질의 데이터를 전달하고, 상기 제1 질의 데이터에 대한 제1 응답 데이터를 상기 제1 REST API로부터 전달받은 후, 상기 제1 질의 데이터와 상기 제1 응답 데이터를 포함하도록 구성된 제1 처리 결과를 상기 제2 오퍼레이터로 전달하고,
   상기 제2 오퍼레이터는, 대응하는 제2 REST API에게 제2 질의 데이터를 전달하고, 상기 제2 질의 데이터에 대한 제2 응답 데이터를 상기 제2 REST API로부터 전달받은 후, 상기 제2 질의 데이터와 상기 제2 응답 데이터를 포함하도록 구성된 제2 처리 결과와 상기 제1 오퍼레이터로부터 전달된 상기 제1 처리 결과를 상기 제3 오퍼레이터로 전달하고,
   상기 제3 오퍼레이터는, 상기 제2 오퍼레이터로부터 전달된 상기 제1 및 제2 처리 결과를 사전에 정의된 집계 방법으로 집계한 후, 그 집계 결과를 제3 처리 결과로서 상기 실행기로 전달하고,
   상기 실행기는,
   상기 제3 처리 결과를 클라이언트에게 반환하는 것인 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 정의된 엔진 컨테이너.
10. 제1항에서,
    상기 다수의 오퍼레이터들은 상기 실행기에 의해 순차적으로 호출되는 제1 오퍼레이터, 제2 오퍼레이터 및 제3 오퍼레이터를 포함하고,
    상기 제1 오퍼레이터는, 대응하는 제1 REST API에게 제1 질의 데이터를 전달하고, 상기 제1 질의 데이터에 대한 제1 응답 데이터를 상기 제1 REST API로부터 전달받은 후, 상기 제1 질의 데이터와 상기 제1 응답 데이터를 포함하도록 구성된 제1 처리 결과를 상기 제2 오퍼레이터로 전달하고,
    상기 제2 오퍼레이터는, 상기 제1 처리 결과에 포함된 상기 제1 응답 데이터를 인덱스로 이용하여, 상기 제1 응답 데이터에 매핑되는 URL 정보를 룩업 테이블로부터 추출하고, 상기 추출된 URL 정보를 포함하도록 구성된 제2 처리 결과를 상기 제3 오퍼레이터로 전달하고,
    상기 제3 오퍼레이터는, 상기 제2 처리 결과에 포함된 상기 URL 정보에 따른 질의 주소에 해당하는 제3 REST API로 제3 질의 데이터를 전달하고, 상기 제3 질의 데이터에 대한 제3 응답 데이터를 상기 제3 REST API로부터 전달받은 후, 상기 제3 응답 데이터를 포함하도록 구성된 제3 처리 결과를 상기 실행기로 전달하고,
    상기 실행기는,
    상기 제3 오퍼레이터로부터 전달된 상기 제3 처리 결과를 클라이언트에게 반환하는 것인 크로스도메인 확장형 워크플로우 엔진 프레임워크에 의해 정의된 엔진 컨테이너.

Images