Windows 워크플로 및 웹 서비스를 사용한 분산 비즈니스 프로세스 배포

워크플로는 비즈니스 기능을 수행하기 위한 사용자와 백 엔드 시스템과의 상호 작용을 관리하는 비즈니스 프로세스를 일련의 작업으로 모델링하고 구현하는 메커니즘을 제공합니다. 사용자의 집중적인 개입이 필요한 비즈니스 프로세스(또는 비즈니스 응용 프로그램)는 여러 엔터티 간의 복잡한 조율 작업으로 인해 일반적으로 오랫동안 실행됩니다. 워크플로를 사용하여 이러한 비즈니스 프로세스를 구현하면 비즈니스 데이터를 조율, 집계 및 라우팅하는 메커니즘을 제공할 수 있습니다.

조직 전체에 걸친 여러 원본으로부터 조율 정보를 얻는 비즈니스 프로세스의 분산 특성으로 인해 워크플로는 분산 응용 프로그램으로 배포하는 것이 바람직합니다. 이러한 기능을 지원하기 위해 Windows® Workflow Foundation 팀은 .NET Framework 3.0 시험판의 초기 버전에서 분산 워크플로 응용 프로그램을 실행하기 위한 플랫폼으로 웹 서비스 및 IIS를 선택했습니다. 가까운 장래에는 Windows Communication Foundation을 기본적으로 지원하도록 확장될 것입니다.

웹 서비스 정의는 응용 프로그램 간 통신 방법을 추상화하도록 고안되었습니다. 웹 서비스는 비즈니스 기능을 수행하기 위해 워크플로에 필요한 상호 작용의 유형을 모델링하는 데 사용됩니다. 웹 서비스를 사용하면 응용 프로그램 간 통신을 표준 방식으로 지원하는 상호 운용 가능한 분산 서비스로 이러한 상호 작용을 구현할 수 있습니다. 이러한 서비스를 사용하면 클라이언트 응용 프로그램 코드에서 비즈니스 논리를 분리할 수 있습니다. 이 메커니즘을 사용하면 서비스 구현을 일반화하여 게시하고 여러 클라이언트에서 이용하도록 할 수 있습니다.

이러한 두 기술을 결합하면 비즈니스 프로세스를 웹 서비스로 공개하는 기능을 제공할 수 있습니다. 또한 비즈니스 상호 작용을 정의하고, 워크플로 하이드레이션 및 디하이드레이션 정책을 활용하여 상태 저장 웹 서비스를 지원하고, 추적 지원을 제공하여 실행 투명성을 구현하는 매크로 웹 서비스를 만들 수 있게 됩니다. 다른 장점은 웹 서비스 요청이 완료된 후에 작업 실행 일정을 예약할 수 있는 기능입니다. 이를 활용하면 웹 서비스 클라이언트에서 직접적인 요청이 없더라도 미리 정의된 간격으로 웹 서비스 요청이 계속 실행되도록 할 수 있습니다. 이 기능은 에스컬레이션 및 시간 제한과 같은 시나리오도 지원합니다. 또한 워크플로 정의의 선언적 특성 덕분에 완전히 선언적인 비즈니스 논리 구현이 가능합니다.

이 기사에서는 Windows Workflow Foundation을 사용하여 장기적으로 실행되는 상태 저장 비즈니스 프로세스를 구현하는 방법과 이를 ASP.NET 웹 서비스로 공개하는 방법을 살펴보겠습니다. 워크플로 런타임은 ASP.NET에서 호스팅되며 장기 실행 워크플로는 Windows Workflow Foundation에 내장된 작업 일정 구조를 사용하여 웹 서비스 호출 이후에도 계속 실행할 수 있습니다. 비즈니스 프로세스는 이러한 기능을 통해 프로세스의 정상적인 실행 흐름에 영향을 주는 에스컬레이션 이벤트를 사용자에게 알릴 수 있습니다.

이 기사에서는 먼저 Windows Workflow Foundation의 선언적 모델링 기술에 대해 검토할 것입니다. 그런 다음 웹 서비스에 대해 검토하고 Windows Workflow Foundation을 사용하여 비즈니스 프로세스를 구현하는 방법과 웹 서비스로 워크플로를 공개하는 방법을 살펴볼 것입니다. 마지막으로 워크플로로 모델링되고 웹 서비스에서 호스팅되는 비용 보고서 예를 살펴보겠습니다. 기사의 말미에 가면 선언적으로 모델링된 워크플로를 사용하여 비즈니스 프로세스를 웹 서비스로 공개하는 방법에 대해 충분히 이해할 수 있을 것입니다.

Windows Workflow Foundation은 웹 서비스를 사용하여 워크플로 내에 모델링된 상호 작용 지점을 웹 서비스 메서드로 공개합니다. 상호 작용 지점은 기반 인터페이스 정의의 기능을 나타내는 웹 서비스 작업을 사용하여 구현됩니다. 그림 1에서 볼 수 있듯이 웹 서비스 작업에는 세 가지가 있습니다.

이러한 작업은 인터페이스에 정의된 메서드에 직접 매핑되며 워크플로 모델 내 웹 서비스의 입력 및 출력 경계를 식별합니다. WebServiceInputActivity가 실행되면 이를 나타내는 인터페이스 메서드가 정의한 입력이 조작을 위해 워크플로에 제공되거나 워크플로 내 속성에 바인딩됩니다. WebServiceInputActivity를 실행한 다음에는 반환 값을 포함하는 인터페이스 메서드에 대해 WebServiceOutputActivity를 실행해야 합니다. 이 작업이 워크플로 인스턴스의 실행을 종료하는 것은 아닙니다. 워크플로 정의 내에 여러 웹 서비스 작업을 모델링할 수 있습니다. 그러나 첫 번째 작업은 워크플로 인스턴스 활성화를 담당하는 요청으로 정의해야 합니다.

WebServiceFaultActivity는 웹 서비스 메서드 호출에 오류 조건을 돌려보내는 데 사용됩니다. WebServiceInputActivity가 WebServiceOutputActivity 또는 WebServiceFaultActivity에 의해 처리된 후에는 워크플로 인스턴스를 해당 작업으로 재배치할 때까지 이를 다시 호출할 수 없습니다. 이 작업은 순차적 워크플로 내의 다양한 루프 구조 또는 상태 시스템 워크플로 내의 SetStateActivity를 사용하여 수행할 수 있습니다.

워크플로 내의 작업 예약은 Delay 작업을 사용하여 수행할 수 있습니다. Delay 작업은 DelayActivity의 TimeSpan 속성에 지정된 간격으로 스케줄러 서비스에 타이머 이벤트를 등록함으로써 작동합니다. Delay 작업은 웹 서비스 요청에 대한 응답이 이루어지기 전에 이 요청을 사용하여 워크플로 인스턴스 내에서 실행됩니다. 그러나 타이머 이벤트 처리는 ManualWorkflowSchedulerService에 의해 별도의 스레드로 수행됩니다. 이로써 워크플로를 모든 웹 서비스 요청에 대해 독립적으로 실행할 수 있게 됩니다. DelayActivity에서 타이머 이벤트를 사용한 후 워크플로는 실행을 계속합니다.

그림 2는 샘플 워크플로의 요소를 보여 줍니다. 웹 서비스 입력 요청은 WebServiceInputActivity에 의해 처리됩니다. PolicyActivity1은 웹 서비스 입력을 조작하고 결과 값을 구성합니다. 그런 다음 WebServiceOutputActivity에 의해 결과 값이 반환됩니다. 그러나 요청 스레드는 워크플로 인스턴스에 의해 해제되기 전에 유휴 상태에 이를 때까지 최대한 많은 작업을 실행하려고 시도합니다. 워크플로는 유휴 상태에 이르면 웹 서비스 요청 스레드를 해제합니다. 이후에 타이머 이벤트가 발생하면 DelayActivity는 별도의 스레드에서 이벤트를 처리하고 PolicyActivity2 실행을 계속합니다. 별도의 스레드는 ManualWorkflowSchedulerService에 의해 할당되고 관리되는 CLR(공용 언어 런타임) 스레드입니다. 워크플로는 PolicyActivity를 사용하여 완전한 선언적 솔루션을 지원하면서 코드를 실행할 수 있습니다. 이로써 웹 서비스의 모든 비즈니스 논리를 선언적 방식으로 표현할 수 있습니다.

페이지 맨 위로

웹 서비스 작업을 사용하여 워크플로를 구축한 후의 마지막 단계는 솔루션을 게시하는 것입니다. 이렇게 하면 IIS가 솔루션을 웹 서비스로 배포하는 데 사용하는 가상 디렉터리가 생성됩니다. 백그라운드에서는 워크플로 라이브러리가 WorkflowWebService 클래스에 의해 래핑됩니다. 이 클래스는 SOAP 요청에서 내부 워크플로 런타임 통신 메커니즘으로 웹 서비스 요청을 전송합니다. 또한 이 클래스는 새 WorkflowRuntime의 인스턴스화도 담당합니다. 이 시스템은 최초의 웹 서비스 요청 시에만 WorkflowRuntime을 인스턴스화합니다. WorkflowWebService 클래스가 워크플로 런타임을 만들면 이를 캐시에 보관했다가 이후 웹 서비스 호출에서 다시 사용할 수 있습니다. 워크플로를 웹 서비스로 게시하면 IIS 서버를 사용하여 손쉽게 워크플로를 호스팅할 수 있습니다.

기본적으로 웹 서비스를 게시할 때 워크플로 런타임은 웹 서비스 요청 스레드를 통해 워크플로 인스턴스를 실행하는 ManualWorkflowSchedulerService를 사용하도록 구성됩니다. 스케줄러가 타이머 이벤트를 처리하는 스레드를 만들어 Delay 작업이 올바르게 동작할 수 있도록 하려면 이 구성을 수정해야 합니다. 이렇게 하려면 UseActiveTimers 플래그를 추가하고 true로 설정하면 됩니다. 이렇게 하지 않으면 워크플로 인스턴스에서 다음 웹 서비스 요청이 사용될 때까지 타이머 이벤트가 처리되지 않습니다. 웹 서비스 게시 단계에서 생성된 web.config 파일에서 구성을 변경해야 합니다.

<add type="System.Workflow.Runtime.Hosting.
               ManualWorkflowSchedulerService, 
           System.Workflow.Runtime, Version=3.0.0.0, 
           Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
     UseActiveTimers="true"/>

장기 실행 워크플로를 지원하기 위해서는 워크플로 런타임 구성을 추가로 수정하여 워크플로 인스턴스가 데이터베이스에 유지되도록 허용해야 합니다. 지속성이 지원되면 워크플로가 유휴 상태가 된 이후에 워크플로의 상태를 데이터베이스에 저장할 수 있습니다. 워크플로가 유지된 이후에 IIS 서버에서 오류가 발생하면 다음 웹 서비스 요청을 받을 때 자동으로 워크플로 런타임이 시작되고 마지막으로 저장된 장소에서 워크플로 인스턴스가 다시 로드됩니다. 지속성을 설정하려면 web.config 파일에 다음 줄을 추가해야 합니다.

<add type="System.Workflow.Runtime.Hosting.
               SqlWorkflowPersistenceService, System.Workflow.Runtime, 
           Version=3.0.0.0, Culture=neutral, 
           PublicKeyToken=31bf3856ad364e35" 
     ConnectionString="Initial Catalog=ASPPersistence;Data 
                       Source=localhost;Integrated Security=SSPI;" 
     UnloadOnIdle="true" />

이 구성은 Windows Workflow Foundation에서 제공하는 SQLWorkflowPersistenceService를 사용합니다. 이 서비스와 연결된 데이터베이스 테이블은 Windows Workflow Foundation 런타임을 설치할 때 함께 설치됩니다. 이 예에서 테이블은 ASPPersistence라는 데이터베이스에 포함되어 있습니다.

프로세스를 처리하는 데는 많은 상호 작용 지점이 필요하므로 더 복잡한 비즈니스 프로세스에는 WebServiceInputActivity를 여러 번 사용해야 합니다. 웹 서비스 클라이언트 응용 프로그램에 동일한 워크플로 인스턴스와 통신하는 능력을 부여하기 위해 HTTP 모듈이 제공됩니다. 이 HTTP 모듈은 표준 웹 서비스 게시 단계의 일부로 자동으로 추가되며 web.config 파일 내에 위치하게 됩니다. HTTP 모듈은 워크플로 인스턴스의 재입력을 구현하기 위해 WF_WorkflowInstanceId라는 클라이언트 쿠키에 워크플로 인스턴스 ID를 저장 및 검색합니다. HTTP 모듈이 쿠키에서 워크플로 인스턴스 ID를 검색한 다음에는 __WorkflowInstanceId__ 키를 사용하여 ID를 현재 HTTP 컨텍스트에 배치합니다. 클라이언트 응용 프로그램이 동일한 워크플로 인스턴스에 대해 여러 웹 서비스 호출을 수행해야 하고 쿠키를 활성화할 수 없는 경우에는 개발자가 HTTP 또는 SOAP 헤더 처리기를 사용하는 대체 방식을 구현해야 합니다.

또한 여러 사용자 지원 시나리오에서는 웹 서비스 상호 작용을 특정 역할로 제한하는 기능도 필요합니다. Windows Workflow Foundation 런타임 환경에서는 이 기능을 지원하기 위해 ASP.NET 역할 공급자 모델을 활용합니다. 이 모델은 특정 역할을 가진 사용자에게서 정보를 검색할 수 있도록 WebServiceInputActivities 제한을 허용합니다. ASP.NET 역할 공급자를 구성하려면 그림 3의 정보를 web.config 파일에 추가해야 합니다. 이 정보는 aspnetdb 데이터베이스에 포함된 SQL 역할 공급자를 사용하도록 웹 서비스를 구성합니다.

페이지 맨 위로

다음은 웹 서비스를 통해 워크플로를 사용하는 시나리오를 살펴보겠습니다. Windows Workflow Foundation 워크플로를 사용하여 구현되고, 외부 이용을 위해 웹 서비스로 공개되는 비용 승인 프로세스를 구현한다고 가정해 보겠습니다. 이 비즈니스 프로세스는 사용자가 비용 보고서를 만든 다음 승인을 위해 제출할 수 있도록 지원해야 합니다. 관리자는 이 과정에 참여하여 비용을 승인하거나 거부할 수 있어야 합니다. 관리자가 제출된 비용을 정해진 기간 동안 확인하지 않은 경우 시스템은 관리자에게 전자 메일 미리 알림을 보내야 합니다. 전자 메일 미리 알림은 관리자가 시스템과 상호 작용하도록 강요하지 않으면서 전송되어야 합니다.

첫 번째 단계는 비용 제출을 처리하는 비즈니스 프로세스를 정의하는 것입니다. 이 모델에서는 입력 및 출력 웹 서비스 작업을 사용하여 클라이언트 응용 프로그램 및 비즈니스 프로세스 간의 상호 작용 지점을 정의할 것입니다. 그림 4는 Windows Workflow Foundation 워크플로를 사용한 비용 승인 프로세스 모델링의 결과를 보여 줍니다.

그림 4 비용 보고서 워크플로 모델 (작게 보려면 이미지를 클릭하십시오.)

그림 4 비용 보고서 워크플로 모델 (크게 보려면 이미지를 클릭하십시오.)

비즈니스 프로세스 모델링을 완료한 다음에는 웹 서비스가 계약할 5개의 상호 작용 지점을 정의해야 합니다. 첫 번째 상호 작용은 시스템에서 비용 보고서를 추적하는 데 사용하는 고유 ID를 반환합니다. 이 정보는 클라이언트로 전송되고 이후의 사용을 위해 서버에 유지됩니다. 그림 5는 이 상호 작용 지점을 위한 메서드 정의와 이에 해당하는 작업 정의를 함께 보여 줍니다.

CreateExpenseReportId를 위한 입력 매개 변수는 정의되지 않았지만 반환 값은 있습니다. 이는 CreateExRInput WebServiceInputActivity에는 매개 변수가 없으며 CreateExROutput WebServiceOutputActivity에는 반환 문자열 값에 매핑되는 ReturnValue 속성이 있음을 의미합니다. PolicyActivity1은 비용 보고서 ID의 생성과 CreateExROutput WebServiceOutputActivity의 일부로 반환될 값의 설정을 담당합니다.

웹 서비스를 통해 워크플로 인스턴스를 다시 입력하는 방법을 보여 주기 위해 필자는 별도의 상호 작용 지점에서 비용 보고서를 제출했습니다. 이 상호 작용 지점은 검토를 위해 완전한 비용 보고서 개체를 비즈니스 프로세스에 제출하는 데 사용됩니다. 이 인터페이스 메서드 정의에는 반환 값이 없습니다(그림 6 참조). 비용 보고서를 워크플로에 제출하면 워크플로는 액수에 따라 제출된 보고서를 검토할 관리자를 결정하거나 백 엔드 시스템에 정보를 유지할 수 있게 됩니다. 이 시나리오에서는 간단한 구현을 위해 별도 데이터 저장소와의 상호 작용은 배제했습니다. 그러나 실제 응용 프로그램이라면 대부분 워크플로 인스턴스를 비용 보고서 데이터의 최종 목적지로 사용하지는 않을 것이며 워크플로 인스턴스는 캐시 역할만 수행할 것입니다.

이 경우 SubmitExRInput WebServiceActivity가 웹 서비스 메서드 호출에 전달된 입력 매개 변수를 받고 이를 워크플로 인스턴스에 포함된 Report 속성에 바인딩합니다. 이제 채워진 보고서 개체를 워크플로에서 처리할 수 있게 됩니다.

비용 보고서가 제출되면 워크플로는 승인 루프로 진입합니다. 루프는 DeclarativeCondition이 있는 WhileActivity를 사용하여 구현됩니다. 이 조건은 비용 보고서 검토를 시작하는 플래그를 확인합니다. 이 플래그는 관리자가 비용 보고서를 승인하거나 거부하면 설정됩니다. WhileActivity에는 ListenActivity가 포함되어 있으며 ListenActivity에는 비용 보고서에 포함된 정보를 쿼리하기 위한 상호 작용 지점, 에스컬레이션 경로, 그리고 거부 또는 승인 상호 작용 지점이 포함되어 있습니다. 에스컬레이션 경로는 DelayActivity를 사용하여 시간 제한을 설정하며 관리자가 비용 보고서를 검토할 수 있는 제한 시간을 정의합니다. 제한 시간 동안 검토하지 않으면 PolicyActivity2를 통해 관리자에게 전자 메일이 트리거됩니다. Timer 이벤트는 내부 메시지이므로 웹 서비스의 계약에 정의될 필요가 없습니다.

상호 작용 지점 쿼리는 입력 및 출력 웹 서비스 작업 한 쌍으로 구현됩니다. ReviewExRInput WebServiceInputActivity는 웹 서비스 요청을 받고 ReviewExROutput WebServiceOutputActivity는 제출된 비용 보고서를 클라이언트 응용 프로그램에 반환합니다. 이는 워크플로 상태의 직접 전달 쿼리이므로 이러한 두 작업 간에 다른 프로세스는 필요하지 않습니다(그림 7 참조).

ListenActivity 내에 포함된 마지막 상호 작용 지점 두 개는 거부 및 승인 작업입니다. 이러한 두 이벤트에는 클라이언트 승인이 필요 없으며 어떠한 유형의 반환 값도 기대하지 않고 호출됩니다. 이들의 목적은 비용 보고서 상태를 설정하고 WhileActivity가 확인하는 검토 플래그를 false로 설정하는 것입니다. 이러한 변수 설정은 PolicyActivity3 및 PolicyActivity4 내에서 수행됩니다(그림 8 참조).

비용 보고서가 승인 또는 거부되면 워크플로 인스턴스는 종료되며 비용 보고서 정보는 Policy 작업을 통해 백 엔드 시스템에 저장됩니다. 이제 웹 서비스는 동일한 인스턴스 ID에 대해 실행할 수 없게 됩니다.

WhileActivity 내 서비스의 흥미로운 측면은 관리자만 실행할 수 있다는 것입니다. 이러한 보안 제약을 적용하기 위해 이 서비스는 관리자 역할로 구성되었습니다.

페이지 맨 위로

Windows Workflow Foundation 작업에서 지원하는 ASMX 기술을 사용하여 웹 서비스를 구현하는 방법에 대해 설명했습니다. 첫 번째 Windows Workflow Foundation 릴리스에서는 새로운 Windows Communication Foundation 서비스 배포를 위한 작업 또는 호스트를 직접 제공하지 않습니다. 이 기능은 이후의 프레임워크 릴리스에서 제공될 것입니다. 그러나 지금 Windows Workflow Foundation에서 Windows Communication Foundation을 사용하는 몇 가지 방법이 있습니다.

• 워크플로 런타임을 호스팅하고 워크플로 인스턴스를 실행하는 Windows Communication Foundation 서비스를 개발합니다.
• 워크플로 정의에서 InvokeWebServicesActivity를 통해 Windows Communication Foundation 서비스에 액세스합니다.
• 사용자 지정 작업을 통해 Windows Communication Foundation 서비스에 액세스합니다.

첫 번째 방법을 사용하면 Windows Communication Foundation 서비스를 워크플로 런타임을 위한 호스트 프로세스로 사용할 수 있습니다. 이 서비스는 미리 정의된 OperationContract가 호출되면 워크플로 실행을 트리거하는 역할을 담당합니다. 이 방식을 사용하면 워크플로가 OperationContract로부터 워크플로 매개 변수로 입력을 받을 수 있습니다. 그림 9는 OperationContract의 예를 보여 줍니다.

Windows Communication Foundation 서비스가 진행 중인 워크플로 인스턴스와 용이하게 상호 작용하도록 하기 위해 다른 상호 작용 지점을 추가 OperationContract 인스턴스로 공개할 수 있습니다. OperationContract의 매개 변수는 워크플로 통신 이벤트 내의 워크플로로 전달됩니다. 그림 9는 ServiceContract를 위한 추가 OperationContract를 보여 줍니다.

 [OperationContract]
public void SendDataToWorkflowApplication(Guid workflowInstanceId, 
  string inputVariable)
{
  WorkflowInstance workflowInstance = 
    workflowRuntime.GetWorkflow(workflowInstanceId);
  internalWFCommunications.SendRequest(
    workflowInstance, inputVariable);
}

InvokeWebServicesActivity를 사용하여 Windows Communication Foundation 서비스를 호출하는 두 번째 방법이 가능한 것은 Windows Communication Foundation에서 SOAP를 지원하기 때문입니다. 아쉽게도 이 방법을 선택하면 Windows Communication Foundation의 WS-* 서비스 지원을 활용할 수 없습니다. 이보다는 세 번째 방법이 더 좋습니다. 즉, 내부 실행 메서드에서 Windows Communication Foundation ServiceProxy를 활용하여 Windows Communication Foundation 서비스를 호출하는 Windows Workflow Foundation 작업을 만드는 것입니다.

protected override ActivityExecutionStatus Execute(
  ActivityExecutionContext executionContext)
{
  RentalReservationsProxy p = new RentalReservationsProxy();
  this.ResultValue = p.MakeReservation(this.InputValue);
  p.Close();
  return base.Execute(executionContext);
}

이 작업을 실행하면 InputValue 속성이 RentalReservationsProxy 클래스로 전달됩니다. 이 작업은 프록시를 사용하여 RentalReservationProxy 서비스에 포함된 MakeReservation OperationContract를 실행하고 WorkflowApplication Windows Communication Foundation 서비스를 추상화하는 프록시 클래스를 반환합니다. MakeReservation 호출은 작업의 InputValue 속성을 입력 매개 변수로 받고 작업의 ResultValue 속성을 설정합니다.

Windows Communication Foundation을 Windows Workflow Foundation과 함께 사용하면 워크플로 자체를 원격 클라이언트에 Windows Communication Foundation 서비스로 공개할 수 있고 작업을 통해 Windows Communication Foundation 서비스를 호출할 수 있습니다.

페이지 맨 위로

다양한 기능의 선언적 Windows Workflow Foundation 모델을 활용하면 비즈니스 프로세스를 공개하고, 이를 실행하기 위한 배포 기술로 웹 서비스를 활용할 수 있습니다. 또한 Windows Communication Foundation 및 Windows Workflow Foundation을 활용하여 견고한 WS-* 호환 비즈니스 응용 프로그램을 게시할 수 있습니다. Windows Workflow Foundation에 대한 자세한 내용 및 .NET Framework 3.0을 사용한 워크플로 개발에 대한 자세한 내용을 보려면 Windows Workflow Foundation 사이트 msdn.microsoft.com/winfx/technologies/workflow (영문)를 방문하십시오. Windows Communication Foundation에 대한 개발자 정보는 msdn.microsoft.com/winfx/technologies/communication (영문)을 참조하십시오.

페이지 맨 위로