서비스 기반 어플리케이션 기반 : 웹 서비스 코디네이션 모델 : 개요, 개념, 정의

Service Integration

웹정보나 서비스를 접근해서 실생활에 활용할 때는 그냥 각각을 독자적으로 사용하진 않습니다. 일반적으로, 여행을 가기 위해서 그 준비에 필요로 하는 정보를 확인할 때 먼저 LonelyPlanet 같은 웹사이트에 가서 여행지의 정보를 확인할 수가 있습니다.

그 이후에는 여행을 실제로 가기 위한 비행기표를 예매하고 호텔을 예약하는 작업을 실제 여행사 사이트를 통해서 수행합니다. 여러 가지 준비가 된 이후에는 실제 여행을 떠나서 목적지에 갔을 때 예기치 못한 날씨를 접할 수도 있습니다. 그래서 날씨도 체크하고 그 지역에 대한 뉴스도 확인할 수 있습니다.

이러한 일련의 웹정보 혹은 서비스를 접근함을 통해서 여행에 관련된 정보를 확인합니다. 그에 대한 실제적인 준비를 할 수가 있습니다. 이러한 과정이 바로 서비스를 coordination하는 과정입니다.

 

 

Web Services Composition

실제로 이런 coordination을 통해서 어플리케이션을 만드는 과정을 web service composition이라고 합니다. 지금 웹서비스들을 선택을 해서 그것들을 coordination함으로써 On-the-fly로 소프트웨어를 만들 수 있습니다. 그리고 이런 On-the-fly 소프트웨어들은 기존의 가용한 웹서비스들을 stream 형태로 호출함으로써 구성이 됩니다.

서비스들은 각각 service provider server에서 동작을 하기 때문에 구성된 어플리케이션은 분산된 어플리케이션입니다. 그리고 이러한 웹서비스를 활용한 어플리케이션 프레임워크가 실현될 경우에, dynamic enterprise, dynamic value chain을 만들 수가 있습니다.

이것은 웹서비스를 제공하는 제공자는 그것을 제공함으로써 이익을 얻습니다. 또한 어플리케이션을 만드는 개발자들은 모든 서비스를 스스로 만들 필요가 없이 이미 제공되는 서비스를 일정의 사용료를 제공을 합니다. 사용할 수 있는 형태,
그래서 전체적인 웹서비스를 생성해내고 활용하는 ecosystem, 생태계가 마련됩니다.

 

 

Layers for Web Services Composition

웹서비스들을 활용하는 전체적인 체계가 설명돼 있습니다. 맨 밑바닥에는 개별적인 웹서비스들이 존재합니다. 이러한 웹서비스들은 웹서비스 플랫폼이란 걸 통해서 인터페이스를 사용한 접근이 일어납니다.

이러한 웹서비스들은 조합되는 틀이 필요합니다. 그런 조합되는 틀을 Business process라고 합니다. 이러한 Business process를 통해서 웹서비스가 조합이 되면, 실제 사용자들이 사용할 수 있는 어플리케이션 형태로 만들어집니다.

웹서비스의 전체적인 조합 구성에서 Business process가 웹서비스 조합의 틀이 됩니다. Business process는 비즈니스를 수행하는 데 필요로 하는 일련의 activity들이 모여 있는 것을 말합니다. 경우에 따라서는 Business process는 sub-process로 구성이 됩니다.

이러한 sub-process는 구체적인 activity들로 이루어져서 표현이 됩니다. 즉 activity들은 더 이상 더 쪼개질 수 없는 단위의 비즈니스 동작입니다. 

 

 

Web Services Orchestration and Choreography

웹서비스를 조합하기 위한 기본적인 모델에는 두 가지가 있습니다. 먼저 orchestration 모델이 있습니다. orchestration 모델은 중앙집중적인 coordination 모델로서, 가운데 여러 주변에 있는 웹서비스들을 coordination할 수 있는 control unit이 존재합니다.

그래서 이러한 centralize된 control에 따라서 필요로 하는 웹서비스들이 호출됩니다. 그래서 사용자가 원하는 task가 수행되는 형태가 바로 orchestration 모델이 됩니다. 이러한 orchestration 모델의 특징은 Business process를 수행 가능하게 만들 수 있습니다. 이러한 orchestration에 사용되는 표준 기술을 BPEL, 즉 Business Process Execution Language라고 부릅니다.

두 번째 웹서비스 coordination 모델을 우리가 choreography 모델이라고 부릅니다. choreography는 우리가 보통 무용을 할 때 사용하는 용어입니다. 무용수들이 무용 공연을 할 때는 지휘자가 없이 서로 간의 상호작용을 통해서 무용, performance를 합니다.

이 경우에도 웹서비스들은 중앙집중적인 control에 따라서 동작하는 것이 아닙니다. 각각의 에이전트가 돼서 상호관계를 통해서 전체적인 task를 수행하는 형식이 바로 choreography 모델이 됩니다. 이러한 choreography를 지원하는 표준이 있습니다. 그것이 WSCI라고 합니다. 즉 Web Service Choreography Interface가 되겠습니다.

 

 

BPEL vs WSCL

이러한 orchestration과 choreography 모델을 실제로 구현하기 위한 기술이 BPEL과 WSCI가 있습니다. 이 둘이 어떻게 차이 나는지 간단히 살펴보도록 하겠습니다.

 

서비스 기반 어플리케이션 기반 : 웹 서비스 코디네이션 모델 : 개요, 개념, 정의

 

BPEL 모델의 특징은 가운데 중앙집중적으로 Business process를 수행하는 요소가 존재합니다. 그래서 트리 형태가 바로 Business process가 됩니다. 왼편 서비스는 바로 이 Business process를 호출하는 다른 웹서비스가 되겠습니다. 그리고 우측에 있는 서비스들은 이 전체적인 Business process를 수행하는 데 필요로 하는 웹서비스입니다. 이 Business process가 호출하는 웹서비스가 됩니다.

BPEL은 이러한 형태로 구성이 돼서 수행합니다. 반면 WSCI의 경우에는 Business process가 가시적으로 보이지 않습니다. 이러한 경우는 각각의 웹서비스가 WSCI라는 에이전트로 감싸 있는 모습을 볼 수 있습니다. 이 에이전트들은 자기가 수행해야 되는 역할을 알고 있습니다. 때문에 그 역할에 따라서 필요로 하는 다른 웹서비스와 상호작용을 collaborative하게 함으로써 전체적인 Business process의 목표를 달성할 수 있도록 하는 모델이 됩니다.

 

서비스 기반 어플리케이션 기반 : 웹 서비스 코디네이션 모델 : 개요, 개념, 정의

 

먼저 BPEL의 예제가 됩니다. BPEL에서는 필요로 하는 일련의 activity들이 sequence로 구성이 됩니다. 그래서 맨 처음에 sequence라는 element가 들어 있습니다. sequence 아래는 첫 번째로 receive라는 element가 있습니다.

이것은 이 Business process를 호출하는 웹서비스가 누군지, 거기서부터 어떠한 input 정보를 받는지가 표현된 것이 바로 receive element가 되겠습니다. 그 이후에는 BPEL에서 수행해야 되는 일련의 서비스 호출들이 flow가 있습니다. 이 flow 안에는 하나의 서비스로 호출하고 있습니다.

그 서비스를 담당하는 파트너가 supply1이라고 지정이 돼 있습니다. 그 supply1에 request port라는 operation을 input값을 줌으로써 invocation하는 모습을 볼 수 있습니다. 그리고 이러한 서비스 호출을 이루어서 어떤 결과가 정리됩니다.

다시 원래 이 전체 Business process를 호출했던 파트너에게 전달을 합니다. 그것이 바로 reply라는 element 입니다. 그래서 처음에 이 Business process를 호출했던 buyer라는 파트너에게 결과값을 전달합니다.

 

서비스 기반 어플리케이션 기반 : 웹 서비스 코디네이션 모델 : 개요, 개념, 정의

 

이 예제에서는 travel agent가 있어서 traveler와의 interaction을 하는 것을 choreography로 나타낸 것이 되겠습니다. BPEL과는 다른 이것은 전체적인 Business process가 아니라 이 travel agent라는 웹서비스가 담당을 해야 되는 역할, 그리고 실제 action들이 정의되었습니다.

WSCI의 정의는 Process라는 element로 시작이 됩니다. 그 안에는 수행해야 되는 action들이 sequential하게 나열이 되어 있습니다. 첫 번째 action은 실제 사용자로부터 여행 정보를 받는 action이 포함이 돼 있습니다. 두 번째 action은 그 여행 정보를 통해서 예약을 confirm하는 작업이 들어 있습니다.

예약에 대한 confirm 과정에서 여기서는 다른 process를 호출하게 됩니다. 비행기의 좌석을 예약하는 book seats라는 process를 호출하게 됩니다. 이것은 WSCI 정의에서 또 하나의 process로 기술이 되어 있습니다. 이런 식으로 WSCI는 BPEL과 다르게 centralize된 control이 있는 것이 아닙니다. 각각의 웹서비스들이 역할을 수행하는 형태로 기술이 됩니다.

이 중에서 일반적으로 BPEL이 가장 많이 활용이 되고 있습니다. 그 이유는 BPEL이 훨씬 더 사용하기 간편합니다. 일반적으로 centralize되게 웹서비스들을 coordination하는 것이 훨씬 더 이해하기도 쉽습니다. manage하기가 쉽습니다.

 

 

BPEL

BPEL은 XML 기반의 언어로서 Business process를 표현하고 수행하는 기술입니다. orchestration 모델을 support하기 위한 기술이 됩니다. BPEL은 원래 IBM, Microsoft, BEA 등 회사들에 의해서 2003년에 제안된 언어가 되겠습니다. 기존의 Microsoft의 XLANG과 IBM의 WSFL이 결합된 형태가 되겠습니다.

현재 이것은 Oasis의 표준으로 되어 있습니다. 이 BPEL을 통해서 우리가 웹서비스를 활용하는 전체적인 기술적인 stack을 완성하게 됩니다. SOAP이라든지, WSDL을 통해서 메시지를 표현하고 교환하고 또 서비스를 검색을 할 수 있습니다.

UDDI라는 기술을 통해서 Directory service를 구성을 할 수 있습니다. 그리고 기술들을 활용을 해서 서비스를 조합함으로써 BPEL을 통해서 어플리케이션을 구성할 수 있습니다. 

 

서비스 기반 어플리케이션 기반 : 웹 서비스 코디네이션 모델 : 개요, 개념, 정의

 

BPEL process의 모습을 다시 보여드리고 있습니다. 여기서는 좀 더 구체적으로 어떤 기업에서 출장 신청을 할 경우에 어느 항공사를 통해서 비행기표를 예약을 해야 되는지 전체적인 과정을 보여줍니다.

왼쪽에 있는 클라이언트는 이 Business process를 호출해서 사용하는 사용자가 됩니다. 오른편에 있는 이 세 개 서비스들은 이 Business process에 사용되는 웹서비스입니다. 첫 번째에 있는 employ travel status 웹서비스는 기업 내부에 있는 웹서비스입니다. 출장 신청을 한 사람이 지금 어떠한 status에 있는지를 확인하는 웹서비스입니다.

두 번째 웹서비스는 American Airline에 있는 웹서비스입니다. 거기서부터 좌석이 가용한지, 값이 어떤지를 알아보는 웹서비스입니다. 세 번째 웹서비스는 Delta Airline으로부터의 웹서비스입니다. American Airline과 유사한 기능을 하는 웹서비스가 되겠습니다.

여기서 synchronous interaction이라고 합니다. 밑에는 asynchronous interaction이라고 합니다. 이것은 기업 내부에 있는 웹서비스는 요청을 보낸 이후에 그 reply가 올 때까지 기다리는 형태를 호출하는 것입니다. 항공사에 대한 웹서비스는 요청을 보낸 이후에 결과가 올 때까지 일정 시간 기다리는 것이 아닙니다. 결과가 오면 notify를 해주는 형태로 호출하는 것이 나타납니다.

 

서비스 기반 어플리케이션 기반 : 웹 서비스 코디네이션 모델 : 개요, 개념, 정의

 

BPEL은 여러 가지 다양한 feature들을 제공을 합니다. 가장 중요한 feature 중에 하나는 전체적인 Business process의 activity들을 표현하는 feature입니다. 이러한 activity를 수행하는 주체인 파트너들을 명세하는 부분입니다. 그리고 파트너로부터 온 메시지를 어떠한 Business process에 할당합니다.

이런 것들을 정하는 message correlation 부분, 그리고 메시지를 저장하기 위한 container 등으로 구성이 되어 있습니다.
그래서 전체적인 BPEL은 process라는 tag 아래 쭉 명시됩니다. 일반적으로 process 아래에다가는 파트너 링크들을 정리합니다.

즉 파트너라는 것은 서비스를 제공하는 제공자를 뜻합니다. 그것들이 명시가 되고, 그 이후에는 일반 프로그래밍 언어처럼 사용하는 variable들이 declare될 수 있습니다. 또한 입력으로 받아들여진 메시지가 어떠한 business process instance와 association이 될지를 설명하는 correlations, 그리고 만약에 어떤 fault가 발생했을 때 그것을 handling하기 위한 fault handler, 그리고 어떤 transaction을 manage하기 위한 compensation handler, 또한 어떤 event가 발생했을 때 handling하는 event handler, 구성이 됩니다.

그리고 가장 중요한 것은 이 전체적인 Business process를 수행하는 acitivity들이 수행되는 process flow가 됩니다. 그런 acitivity들은 웹으로부터 입력값을 받는 것, 그리고 결과값을 주는 reply, 또 다른 서비스를 호출하는 invoke, 이러한 element들로 일반적으로 구성이 됩니다.

 

 

BPEL Activity Types

서비스 기반 어플리케이션 기반 : 웹 서비스 코디네이션 모델 : 개요, 개념, 정의

 

BPEL을 구성하는 가장 중요한 요소는 activity를 명시하는 부분이 되겠습니다. activity의 타입은 이렇게 네 가지로 정리가 됩니다. 먼저 전체적인 activity들의 구성을 표현하는 structuring activity가 있습니다. 일반 프로그래밍 언어처럼 순차적인 activity의 수행, 혹은 동시에 수행하는 activity를 명시하는 flow, 또는 어떠한 조건에 따라서 acitivity를 선택하는 switch, 이런 것들로 구성이 돼 있습니다.

또 loop도 wire loop 같은 반복적인 root도 표현할 수 있습니다. 그리고 두 번째 communication activity는 Business process를 호출하는 파트너로부터 입력을 받는 receive라든지, 결과를 주는 invoke, 그리고 reply, 그리고 다른 웹서비스를 호출하는 invoke activity들이 바로 communication activity가 되겠습니다.

그 외에도 어떠한 변수에다가 assign한 assign activity, 또 어떠한 값을 기다리는 wait, 이러한 것들이 바로 다른 activity가 되겠습니다. 또한 어떤 fault가 발생했을 때 그것을 감지해서 exception handling을 하기 위한 exception handling activity들로 구성이 되어 있습니다. 이 중에서 activity는 communication activity가 됩니다.

 

 

Communication Activities

첫 번째 communication activity는 invoke입니다. invoke는 두 가지, 즉 synchronous invocation과 asynchronous invocation 형태로 이루어질 수 있습니다.

첫 번째 예는 synchronous하게 invocation을 하는 예제입니다. 보시면 cable operator라는 파트너로부터 get subscription status라는 operation을 호출하는 예입니다. 여기는 input이 input container를 통해서 지정된 것뿐만 아니라 또한 output container가 지정되어 있습니다.

그 말은 이러한 서비스 호출이 일어난 이후에는 이 output container의 실제 결과값이 도달할 때까지 기다리는 synchronous한 호출을 의미합니다. 반면에 asynchronous한 호출을 받는 예를 살펴보시면 동일한 파트너에 동일한 operation 호출하지만, input container만 지정이 돼 있고, output container는 지정이 되어 있지 않습니다.

이 말은 input을 지정해서 호출을 한 이후에 계속 기다리는 것이 아니라 output이 도달하면 그 event를 감지해서 그 다음에 처리를 하는 구조입니다. 그러면 asynchronous한 호출이었을 때 결과값을 바로 receive라는 activity를 수행함으로써 가능합니다.

그래서 receive라는 activity는 파트너로부터 어떤 결과값이 올 때까지 기다리는, 별도의 thread를 통해서 기다리는 activity가 됩니다. 여기서 보시는 것처럼 결과값을 기다리는 container를 지정하게 되겠습니다. 그 이후에는 그 결과값이 도달하면 해야 되는 조치를 나열할 수 있습니다.

그리고 마지막 communication activity는 reply activity가 되겠습니다. 그것은 바로 Business process를 호출한 서비스에 Business process를 수행한 결과를 전달을 하는 activity가 됩니다. invoke와 유사하게 파트너가 명시가 됩니다. 결과값이 저장이 된 container가 명시가 됩니다.

 

 

Sequence & Flow Activities

structuring activity의 주요한 사항에 대해서 살펴보겠습니다. structuring activity에는 앞서서 sequence와 flow가 있습니다. sequence는 그 의미 그대로 invocation의 sequence를 정의를 하는 것입니다. 

즉 이 invocation들, 서비스에 대한 호출들은 순차적으로 이루어진다는 의미입니다. 반면에 flow라는 activity 안에 서비스에 대한 호출들을 넣게 됩니다. 이 호출들은 동시에 parallel하게 이루어지게 되겠습니다. 그래서 이러한 parallel한 activity들은 서로 dependency가 없이 서로 독립적으로 호출이 됩니다.

그래서 이러한 sequence와 flow를 결합을 해서 사용을 할 수가 있습니다. 즉 전체적인 웹서비스된 호출은 sequential하게 이루어지지만 두 번째 단계에서 웹서비스 호출은 세 개가 동시에, 즉 호텔 웹서비스, 그리고 렌터카에 대한 웹서비스, 그리고 항공사에 대한 웹서비스가 동시에 호출이 됩니다. 그 결과값이 서로 join이 돼서 세 번째 호출이 일어납니다.

 

 

Conditional Activities

conditional activity는 어떠한 조건을 체크를 합니다. 그거에 따라서 어떤 activity를 수행하는 것을 표현할 수 있습니다. 하나의 예로서 input statement를 if activity 이름을 먼저 지정을 하고 그 아래 condition element의 표현이 됩니다.

이 condition 표현을 보시면 어떠한 변수에서 그 값을 추측을 합니다. 그 값이 10이라는 값보다 큰가 하는 것을 체크합니다. 부등호를 &%gt; 이렇게 표현했습니다.

부등호를 이러한 조건문 안에 넣으면 일반적인 XML tag를 표현하는 표현과 중복이 됩니다. 그러한 중복을 피하기 위해서 이러한 특별한 표현법을 쓰게 됩니다. 그리고 이러한 조건이 만족되면 그 아래에 있는 것처럼 calculate the charge라는 서비스를 호출하게 됩니다. 이런 condition을 만족하지 않을 때는 또 다른 action을 취해서 어떠한 reply를 합니다. 

 

서비스 기반 어플리케이션 기반 : 웹 서비스 코디네이션 모델 : 개요, 개념, 정의

 

BPEL을 사용해서 만든 Hello World 프로그램이 있습니다. BPEL은 process element라고 하는 것으로부터 시작을 하게 되겠습니다. 그 아래 이 BPEL process를 호출하는 호출 파트너가 명시돼 있는 모습을 보실 수 있습니다. 그리고 파트너에 대한 정의 이후에는 이 BPEL에서 사용되는 변수들, variable들이 정의가 돼 있는데 두 가지, request와 response라는 variable이 정의된 모습이 있습니다.

request라는 variable은 name message라는 형태의 메시지를 저장할 수 있습니다. 또 response는 greeting message라는 메시지 타입을 저장할 수 있다고 지정이 되어 있습니다. 그리고 그 이후에는 수행에 대한 activity의 sequence가 나열이 되어 있습니다.

그런 activity의 sequence의 첫 번째는 바로 파트너인 caller로부터 그 caller의 이름을 받는 receive activity가 지정이 돼 있습니다. 그리고 그 다음 activity는 assign이라는 activity입니다. 여기는 caller로부터 받은 이름을 다른 hello나 string과 결합을 해서 실제 caller에게 다시 보낼 메시지를 구성하는 부분이 되어 있습니다.

그리고 이러한 구성된 string을 앞서서 정의된 response라는 variable에다 copy를 함으로써 이것을 caller에게 다시 전달할 수 있는 준비를 하는 과정이 됩니다. 그리고 마지막 activity는 reply activity로서 만들어진 Hello World string을 실제 caller에게 다시 전달하는 과정이 됩니다.

 

 

BPEL Designer Project

어플리케이션을 만드는 작업을 쉽게 할 수 있는 도구들이 많이 제공이 되고 있습니다. Eclipse의 Plug-in 형태로 사용할 수 있는 BPEL designer project라는 도구입니다. 이런 도구를 사용하시면 어떠한 GUI(Graphical User interface) 인터페이스를 통해서 graphical하게 BPEL의 Business process를 구성하고 이런 것들을 서비스와 연계시켜서 수행할 수 있겠습니다.

또한 BPEL로 표현된 어플리케이션들을 처리하기 위한 다양한 BPEL 엔진이 있습니다. 이러한 BPEL 엔진들은 사용하고 계신 플랫폼이나 좋아하시는 언어에 따라서 선택해서 활용합니다.