워크플로 방법: Windows Workflow Foundation 이해

아티클
01/12/2010

데이비드 샤펠
샤펠 & 어소시에이츠

2009년 4월

이 문서 다운로드

Word 서식
PDF

Windows Workflow Foundation 소개

코드를 작성하는 모든 사람은 훌륭한 소프트웨어를 빌드하려고 합니다. 해당 소프트웨어가 서버 애플리케이션인 경우 크기가 잘 조정되어 너무 많은 리소스를 사용하지 않고 큰 부하를 처리하는 것이 좋습니다. 또한 훌륭한 애플리케이션은 작성자와 이를 유지 관리하는 사용자 모두에게 가능한 한 쉽게 이해할 수 있어야 합니다.

이 두 가지 목표를 모두 달성하는 것은 쉽지 않습니다. 애플리케이션 크기를 조정하는 데 도움이 되는 접근 방식은 논리를 이해하기 어려운 별도의 청크로 나누어 분리하는 경향이 있습니다. 그러나 단일 실행 파일에 있는 통합 논리를 작성하면 애플리케이션 크기를 조정하는 것이 불가능할 수 있습니다. 필요한 것은 애플리케이션의 논리를 통합된 상태로 유지하여 애플리케이션 크기를 조정하면서 더 쉽게 이해할 수 있도록 하는 방법입니다.

이를 달성하는 것은 WF(Windows Workflow Foundation)의 주요 목표입니다. WF는 워크플로를 사용하여 만든 논리를 지원함으로써 통합되고 확장 가능한 애플리케이션을 만들기 위한 토대를 제공합니다. 이와 함께 WF는 병렬 작업 조정, 프로그램 실행 추적 등과 같은 다른 개발 과제를 간소화할 수 있습니다.

WF는 2006년에 .NET Framework 3.0으로 처음 릴리스된 후 .NET Framework 3.5에서 업데이트되었습니다. 이러한 처음 두 버전은 특히 ISV(독립 소프트웨어 공급업체)에 유용했지만 엔터프라이즈 개발자를 위한 주류 기술이 되지는 않았습니다. .NET Framework 4의 일부인 WF 버전을 사용하여 작성자는 이를 변경하는 것을 목표로 합니다. 이 최신 릴리스의 주요 목표는 WF를 모든 .NET 개발자를 위한 프로그래밍 도구 키트의 표준 부분으로 만드는 것입니다.

다른 기술과 마찬가지로 WF를 적용하려면 WF가 무엇인지, 왜 유용한지, 그리고 사용하는 것이 합리적일 때를 이해해야 합니다. 이 개요의 목표는 이러한 사항을 명확하게 하는 것입니다. WF 애플리케이션을 작성하는 방법은 배우지 않지만 WF가 제공하는 기능, WF가 제공하는 방식 및 개발자의 삶을 개선할 수 있는 방법을 살펴보겠습니다. 즉, 워크플로 방법을 이해하기 시작합니다.

과제: 통합되고 확장 가능한 애플리케이션 논리 작성

프로그램을 작성하는 간단한 방법 중 하나는 단일 컴퓨터에서 단일 프로세스로 실행되는 통합 애플리케이션을 만드는 것입니다. 그림 1에서는 이 아이디어를 보여 줍니다.

그림 1: 애플리케이션 논리를 통합된 전체로 만든 다음 단일 컴퓨터에서 실행되는 프로세스의 특정 스레드에서 실행할 수 있습니다.

이 예제의 간단한 의사 코드는 애플리케이션에서 일반적으로 수행하는 작업 종류를 보여 줍니다.

여기서는 단순 문자열 변수로 표시되는 상태를 유지 관리합니다.
클라이언트에서 요청을 수신하는 등 외부 환경에서 입력을 가져옵니다. 간단한 애플리케이션은 콘솔에서 읽기만 할 수 있지만, 더 일반적인 예제는 웹 브라우저에서 HTTP 요청 또는 다른 애플리케이션의 SOAP 메시지를 받을 수 있습니다.
외부 세계로 출력을 보냅니다. 빌드 방법에 따라 애플리케이션은 HTTP, SOAP 메시지, 콘솔에 쓰기 또는 다른 방법으로 이 작업을 수행할 수 있습니다.
if/else 및 while와 같은 제어 흐름 문을 사용하여 논리를 통해 대체 경로를 제공합니다.
애플리케이션의 각 지점에서 적절한 코드를 실행하여 작업을 수행합니다.

여기에 표시된 통합 접근 방식에서 애플리케이션 논리는 단일 컴퓨터의 특정 프로세스 내 스레드에서 전체 수명을 실행합니다. 이 간단한 방법은 몇 가지 장점이 있습니다. 한 가지, 논리는 간단하고 통합된 방식으로 구현될 수 있습니다. 이렇게 하면 코드로 작업하는 사용자가 이를 이해하는 데 도움이 되며 허용된 이벤트 순서도 명시적입니다. 예를 들어 그림 1에서는 클라이언트의 첫 번째 요청이 두 번째 요청보다 우선해야 하며 프로그램의 제어 흐름에 필요합니다. 두 번째 요청이 도착하면 애플리케이션을 통한 다른 경로가 없으므로 첫 번째 요청이 이미 처리되었는지 확인할 필요가 없습니다.

이 방법의 또 다른 장점은 애플리케이션의 상태를 사용하는 것이 쉽다는 것입니다. 해당 상태는 프로세스의 메모리에 유지되며 프로세스가 작업이 완료될 때까지 계속 실행되므로 상태는 항상 사용할 수 있습니다. 개발자는 일반 변수에만 액세스합니다. 더 간단할 수 있는 것은 무엇인가요?

그러나 이 기본 프로그래밍 스타일에는 제한 사항이 있습니다. 애플리케이션이 콘솔의 사용자, 웹 서비스 클라이언트 또는 다른 사용자로부터 입력을 기다려야 하는 경우 일반적으로 차단됩니다. 스레드와 사용하는 프로세스는 입력이 도착할 때까지 유지되지만 시간이 오래 걸립니다. 스레드와 프로세스는 리소스가 상대적으로 부족하기 때문에 입력을 기다리고 있을 때 둘 중 하나를 유지하는 애플리케이션은 크기가 잘 조정되지 않습니다.

더 확장 가능한 방법은 입력을 대기할 때 애플리케이션을 종료한 다음 입력이 도착하면 다시 시작하는 것입니다. 애플리케이션이 필요하지 않을 때 스레드 또는 프로세스를 유지하지 않으므로 이 방법은 리소스를 낭비하지 않습니다. 이렇게 하면 애플리케이션이 서로 다른 시간에 다른 컴퓨터의 여러 프로세스에서 실행할 수도 있습니다. 그림 1과 같이 단일 시스템에 잠기지 않고 사용 가능한 여러 컴퓨터 중 하나에서 애플리케이션을 실행할 수 있습니다. 이렇게 하면 여러 컴퓨터에 작업을 보다 쉽게 분산할 수 있으므로 확장성도 향상됩니다. 그림 2는 이 모양이 어떻게 보이는지 보여줍니다.

그림 2: 애플리케이션 논리는 서로 다른 컴퓨터에서 실행할 수 있는 모든 공유 공통 상태인 청크로 나눌 수 있습니다.

이 예제 애플리케이션은 이전과 동일한 논리를 포함하지만 이제는 별도의 청크로 나뉩니다. 클라이언트의 첫 번째 요청을 받으면 적절한 청크가 로드되고 실행됩니다. 이 요청이 처리되고 응답이 다시 전송되면 이 청크를 언로드할 수 있습니다. 메모리에 남아 있을 필요는 없습니다. 클라이언트의 두 번째 요청이 도착하면 클라이언트를 처리하는 청크가 로드되고 실행됩니다. 그림 2에서 알 수 있듯이 이 청크는 첫 번째 청크의 다른 컴퓨터에서 실행되는 다른 프로세스의 다른 스레드에서 실행할 수 있습니다. 요청이 처리되면 이 두 번째 청크를 언로드하여 사용하던 메모리를 해제할 수도 있습니다.

이러한 방식으로 작동하는 기술의 한 가지 일반적인 예는 ASP.NET. 개발자는 ASP.NET 애플리케이션을 각각 애플리케이션 논리의 일부를 포함하는 페이지 집합으로 구현합니다. 요청이 도착하면 올바른 페이지가 로드되고 실행된 다음 다시 언로드됩니다.

이 스타일로 빌드된 애플리케이션은 앞에서 보여 준 간단한 방법을 사용하여 만든 것보다 기계 리소스를 더 효율적으로 사용할 수 있으므로 크기가 더 향상됩니다. 그러나 복잡성을 통해 향상된 확장성에 대한 대가를 지불했습니다. 한 가지, 그림 2와 같이 다양한 코드 청크가 어떻게든 상태를 공유해야 합니다. 각 청크는 요청 시 로드되고 실행된 다음 종료되므로 이 상태는 데이터베이스 또는 다른 지속성 저장소와 같이 외부에 저장되어야 합니다. 이제 개발자는 그림 1에 표시된 시나리오와 같이 일반 변수에 액세스하는 대신 애플리케이션의 상태를 획득하고 저장하기 위해 특별한 작업을 수행해야 합니다. 예를 들어 ASP.NET 애플리케이션에서 개발자는 데이터베이스에 직접 상태를 쓰거나 Session 개체에 액세스하거나 다른 방법을 사용할 수 있습니다.

이 향상된 확장성의 또 다른 비용은 코드가 더 이상 프로그램의 전체 논리에 대한 통합 보기를 제공하지 않는다는 것입니다. 그림 1에 표시된 버전에서는 프로그램에서 입력이 필요한 순서가 분명합니다. 코드를 통해 가능한 경로는 하나뿐입니다. 그러나 그림 2의 버전에서는 이 제어 흐름이 분명하지 않습니다. 실제로 클라이언트의 두 번째 요청을 처리하는 코드 청크는 첫 번째 요청이 이미 완료되었는지 확인하여 시작해야 할 수 있습니다. 모든 종류의 중요한 비즈니스 프로세스를 구현하는 애플리케이션의 경우 다양한 청크에서 제어 흐름을 이해하고 올바르게 구현하는 것이 어려울 수 있습니다.

통합 애플리케이션을 작성하면 개발자의 생활과 코드를 쉽게 이해할 수 있지만 결과는 잘 조정되지 않습니다. ASP.NET 애플리케이션과 같이 외부 상태를 공유하는 청키 애플리케이션을 작성하면 확장성이 가능하지만 상태를 관리하기가 더 어려워지고 통합 제어 흐름이 손실됩니다. 간단한 상태 관리를 사용하여 확장 가능한 비즈니스 논리를 작성하지만 애플리케이션의 제어 흐름에 대한 통합된 보기를 갖습니다.

이것이 바로 워크플로 방식에서 제공하는 것입니다. 다음 섹션에서는 방법을 보여줍니다.

솔루션: 워크플로 방법

WF 애플리케이션이 이러한 문제(및 기타)를 해결하는 방법을 이해하려면 WF 작동 방식의 기본 사항을 탐색해야 합니다. 그 과정에서 이 기술이 놀라울 정도로 많은 수의 사례에서 개발자의 삶을 더 좋게 만드는 이유를 살펴보겠습니다.

통합 애플리케이션 논리 만들기

WF를 사용하여 만든 워크플로 기반 애플리케이션은 일반 애플리케이션과 동일한 종류의 작업을 수행합니다. 상태를 유지하고, 입력을 가져오고, 외부 세계로 출력을 보내고, 제어 흐름을 제공하고, 애플리케이션의 작업을 수행하는 코드를 실행합니다. 그러나 WF 워크플로에서는 이러한 모든 작업이 활동에 의해 수행됩니다. 그림 3에서는 비교를 위해 통합 코드 접근 방식과 함께 이 모양이 어떻게 표시되는지 보여 줍니다.

그림 3: WF 워크플로에서 프로그램의 모든 작업은 활동에 의해 수행됩니다.

그림 3에서 알 수 있듯이 모든 워크플로에는 다른 모든 작업이 포함된 가장 바깥쪽 활동이 있습니다. 여기서 이 가장 바깥쪽 활동은 Sequence라고 하며, 일반 프로그램과 마찬가지로 상태를 유지하는 변수를 가질 수 있습니다. 시퀀스는 복합 작업이므로 다른 작업도 포함할 수 있습니다.

이 간단한 예제에서 워크플로는 외부 세계에서 입력을 가져오는 ReceiveMessage 작업으로 시작합니다. 그 다음에는 분기를 구현하는 If 작업이 뒤따릅니다. 또한 복합 작업인 경우 각 분기에서 수행된 작업을 실행하는 다른 작업(여기서는 X 및 Y로 레이블이 지정됨)을 포함합니다. If 활동 뒤에는 이 워크플로를 넘어 전 세계에 일부 출력을 보내는 SendMessage 작업이 잇습니다. 다음에 다른 ReceiveMessage 작업이 나타나고, 더 많은 입력을 받은 다음 While 활동이 뒤따릅니다. 다른 작업인 Z가 포함되어 있지만 이 작업은 while 루프를 수행합니다. 전체 워크플로는 최종 SendMessage 활동으로 종료되어 프로그램의 최종 결과를 보냅니다.

그림 2의 일치하는 색에서 알 수 있듯이 이러한 모든 활동은 일반적인 프로그램의 다양한 부분에 기능적으로 해당합니다. 그러나 기존 프로그램에서처럼 기본 제공 언어 요소를 사용하는 대신 WF 워크플로의 각 작업은 실제로 클래스입니다. 워크플로 실행은 활동을 실행하는 방법을 알고 있는 구성 요소인 WF 런타임에 의해 수행됩니다. 그림 4에서는 이 아이디어를 보여 줍니다.

그림 4: WF 런타임은 워크플로에 의해 결정된 순서대로 활동을 실행합니다.

워크플로 실행을 시작하면 WF 런타임은 먼저 가장 바깥쪽 작업을 실행합니다. 이 예제에서는 시퀀스입니다. 그런 다음, 해당 작업 내에서 첫 번째 작업을 실행합니다. 여기서는 ReceiveMessage, 다음 활동 등이 있습니다. 특정 상황에서 정확히 어떤 활동이 실행되는지는 워크플로를 통해 수행되는 경로에 따라 달라집니다. 예를 들어 첫 번째 ReceiveMessage 작업에서 한 종류의 입력을 가져오면 If 활동에서 활동 X를 실행할 수 있지만 다른 종류의 입력으로 인해 작업 Y가 실행될 수 있습니다. 그것은 다른 프로그램과 같습니다.

WF 런타임은 실행 중인 활동의 내부 사항에 대해 전혀 알지 못한다는 것을 이해하는 것이 중요합니다. ReceiveMessage에서 If를 알 수 없습니다. 이 작업을 수행하는 방법을 아는 유일한 방법은 활동을 실행한 다음 다음 작업을 실행하는 것입니다. 그러나 런타임은 활동 간의 경계를 볼 수 있지만, 여기서 볼 수 있는 것은 유용한 일입니다.

이 작업의 중요한 내용은 WF가 워크플로를 설명하기 위한 특정 언어를 정의하지 않는다는 것입니다. 모든 것은 개발자가 사용하기로 선택한 활동에 따라 달라집니다. 생활을 더 쉽게 하기 위해 WF에는 광범위하게 유용한 활동 집합을 제공하는 BAL(기본 활동 라이브러리)이 포함되어 있습니다. (여기서 사용되는 모든 예제 활동은 실제로 BAL에서 가져옵니다.) 그러나 개발자는 좋아하는 다른 활동을 자유롭게 만들 수 있습니다. 그들은 심지어 완전히 BAL을 무시하도록 선택할 수 있습니다.

여기에 명백한 질문이있다 : 왜이 모든 문제로 이동? 활동을 사용하여 프로그램을 만드는 것은 개발자가 사용하는 것과 다르므로 누군가가 귀찮게하는 이유는 무엇입니까? 일반 코드를 작성하는 것은 어떨까요?

물론 대답은 이 방법이 더 나은 코드를 만드는 데 도움이 될 수 있다는 것입니다. 예를 들어 워크플로 방식은 개발자에게 통합 제어 흐름을 제공합니다. 그림 1에 표시된 간단한 경우와 마찬가지로 프로그램의 기본 논리는 하나의 일관된 스트림에 정의됩니다. 이렇게 하면 쉽게 이해할 수 있으며 논리가 청크로 분할되지 않으므로 추가 검사가 필요하지 않습니다. 워크플로 자체는 허용되는 제어 흐름을 표현합니다.

이는 통합 애플리케이션 논리를 만드는 목표의 절반을 나타냅니다. 그러나 WF 애플리케이션은 후반기를 완료하여 간단한 상태 관리로 확장 가능한 애플리케이션을 만들 수도 있습니다. 다음 섹션에서는 워크플로 방법을 통해 이를 가능하게 하는 방법을 설명합니다.

확장성 제공

확장성을 위해 서버 애플리케이션을 단일 컴퓨터의 단일 프로세스에 잠글 수 없습니다. 그러나 ASP.NET 페이지에서와 같이 애플리케이션 논리를 청크로 명시적으로 분리하면 통합 제어 흐름이 중단됩니다. 또한 프로그래머가 상태를 명시적으로 사용하도록 강제합니다. 실제로 원하는 것은 논리를 다른 컴퓨터의 다른 프로세스에서 실행할 수 있는 청크로 자동으로 분할하는 방법입니다. 또한 애플리케이션의 상태를 관리하려고 하므로 액세스 변수만 있으면 됩니다.

이것이 바로 워크플로가 제공하는 것입니다. 그림 5에서는 WF가 이러한 작업을 수행하는 방법의 기본 사항을 보여 줍니다.

그림 5: WF 런타임은 입력을 기다리는 동안 워크플로를 언로드한 다음 입력이 도착하면 다시 로드합니다.

다른 애플리케이션과 마찬가지로 WF 워크플로는 입력 대기를 차단합니다. 예를 들어 그림 5에서는 클라이언트의 두 번째 요청을 기다리는 두 번째 ReceiveMessage 작업에서 워크플로가 차단됩니다(1단계). WF 런타임은 이를 확인하므로 워크플로의 상태와 워크플로가 지속성 저장소에서 다시 시작해야 하는 위치 표시(2단계)를 저장합니다. 이 워크플로에 대한 입력이 도착하면(3단계) WF 런타임은 영구적 상태를 찾은 다음 워크플로를 다시 로드하여 중단된 위치에서 실행을 선택합니다(4단계). 이 모든 작업은 자동으로 수행됩니다. WF 개발자는 아무 작업도 수행할 필요가 없습니다. WF 런타임은 워크플로로 볼 수 있으므로 이러한 모든 세부 정보 자체를 처리할 수 있습니다.

이 방법의 한 가지 명백한 이점은 워크플로가 스레드를 차단하고 입력을 기다리는 동안 프로세스를 사용하는 메모리에서 중단되지 않는다는 것입니다. 또 다른 장점은 지속형 워크플로가 원래 실행 중이던 컴퓨터가 아닌 다른 컴퓨터에 다시 로드될 수 있다는 것입니다. 이 때문에 그림 6과 같이 워크플로의 여러 부분이 다른 시스템에서 실행될 수 있습니다.

그림 6: 워크플로는 수명 동안 다른 스레드, 다른 프로세스 및 다른 컴퓨터에서 실행될 수 있습니다.

이 예제에서는 워크플로가 컴퓨터 A의 프로세스에서 첫 번째 클라이언트 요청을 처리한다고 가정합니다. 두 번째 ReceiveMessage로 인해 워크플로가 입력 대기를 차단하면 WF 런타임은 설명한 대로 워크플로의 상태를 지속성 저장소로 언로드합니다. 클라이언트의 두 번째 요청이 도착하면 이 워크플로를 컴퓨터 B의 프로세스로 다시 로드할 수 있습니다. 특정 컴퓨터의 특정 프로세스에서 특정 스레드에 잠기는 대신 필요에 따라 WF 워크플로를 이동할 수 있습니다. 개발자는 WF에서 자동으로 제공하는 이 민첩성을 무료로 받습니다.

WF 런타임은 워크플로가 입력을 기다려야 하는 시간을 신경 쓰지 않는다는 점을 지적할 필요가 있습니다. 워크플로가 유지된 후 몇 초 후, 몇 분 후 또는 몇 달 후에 도착할 수 있습니다. 지속성 저장소가 워크플로의 상태를 유지하는 한 해당 워크플로를 다시 시작할 수 있습니다. 따라서 WF는 장기 실행 프로세스를 구현하는 애플리케이션을 빌드하기 위한 매력적인 기술입니다. 예를 들어 채용 프로세스를 지원하는 애플리케이션은 초기 인터뷰 예약부터 새 직원을 조직에 통합하는 것까지 모든 것을 포함합니다. 이 프로세스는 몇 주 또는 몇 달 동안 지속될 수 있으므로 WF를 사용하여 애플리케이션의 상태를 관리하는 것이 좋습니다. 그러나 WF는 이러한 종류의 장기 실행 프로세스에 매우 유용할 수 있지만 이것이 유일한 목적은 아니라는 것을 이해하는 것이 중요합니다. 통합되고 확장 가능한 논리가 필요한 모든 애플리케이션은 WF에 적합한 후보가 될 수 있습니다.

실제로 그림 6을 다시 살펴보세요. 두툼한 애플리케이션(예: ASP.NET 만 빌드)이 확장성을 달성한 방법을 보여 준 그림 2와 비슷하지 않나요? 실제로 그림 6은 선형 제어 흐름으로 빌드된 통합 애플리케이션을 보여 준 그림 1과도 매우 유사하지 않나요? WF는 이러한 두 가지 작업을 모두 수행합니다. 애플리케이션의 제어 흐름은 이해할 수 있고 통합된 방식으로 표현되며 단일 컴퓨터의 단일 프로세스에 잠겨 있지 않으므로 애플리케이션의 크기를 조정할 수 있습니다. 이것이 워크플로 방식의 아름다움입니다.

그리고 그게 전부가 아닙니다. WF를 사용하는 것도 다른 장점이 있습니다. 예를 들어 병렬 작업을 보다 쉽게 조정할 수 있습니다. 예를 들어 애플리케이션의 진행률을 추적하는 데 도움이 됩니다. 다음 섹션에서는 이러한 기술 측면을 살펴봅니다.

워크플로 방법의 다른 이점

WF 워크플로는 WF 런타임에서 실행되는 활동으로 구성됩니다. WF 세계를 이해하는 데는 약간의 노력이 필요하지만, 이 스타일로 애플리케이션 논리를 작성하면 다음에 설명된 대로 일반적인 프로그래밍 문제를 더 쉽게 수행할 수 있습니다.

병렬 작업 조정

WF BAL에는 친숙한 프로그래밍 언어 문에 해당하는 활동이 포함되어 있습니다. 이 때문에 일반적인 프로그램처럼 동작하는 워크플로를 작성할 수 있습니다. 그러나 WF 런타임이 있으면 기존 프로그래밍 언어 이상을 제공하는 활동을 만들 수도 있습니다. 이 작업의 중요한 예는 워크플로를 사용하여 병렬 작업을 보다 쉽게 조정하는 것입니다.

혼동하지 마세요. 여기서는 다중 코어 프로세서에서 동시에 실행되는 병렬 코드를 작성하는 데 중점을 두지 않습니다. 대신, 두 웹 서비스를 호출한 다음 두 결과를 모두 기다린 후 계속해야 하는 애플리케이션을 생각해 보세요. 호출을 병렬로 실행하는 것은 순차적으로 수행하는 것보다 훨씬 빠르지만 이 작업을 수행하는 기존 코드를 작성하는 것은 간단하지 않습니다. .NET Framework는 이러한 호출을 비동기적으로 수행하는 다양한 방법을 제공하지만, 그 중 어느 것도 특히 간단하지 않습니다. 워크플로 방식이 빛을 발할 수 있는 또 다른 상황입니다. WF를 통해 이 작업을 쉽게 수행할 수 있습니다. 그림 7은 방법을 보여줍니다.

그림 7: 병렬 작업 내에 포함된 활동은 병렬로 실행됩니다.

이 그림은 이전 예제와 매우 유사한 간단한 워크플로를 보여줍니다. 가장 큰 차이점은 이제 두 개의 웹 서비스를 호출한 다음 계속하기 전에 둘 다의 응답을 기다린다는 것입니다. 이러한 호출을 병렬로 실행하기 위해 워크플로 작성자는 병렬 작업 내에서 SendMessage 및 ReceiveMessage 작업 쌍을 모두 래핑했습니다. 병렬은 WF의 기본 활동 라이브러리의 표준 부분이며, 해당 이름이 제안하는 것을 정확하게 수행합니다. 포함된 활동을 병렬로 실행합니다. 개발자가 이를 처리하는 복잡성을 처리하는 대신 WF 런타임 및 병렬 작업은 많은 작업을 수행합니다. 개발자가 해야 할 일은 문제를 해결하기 위해 필요에 따라 활동을 준비하는 것입니다.

자동 추적 제공

WF 런타임은 워크플로 활동 간의 경계를 볼 수 있으므로 각 활동이 시작되고 끝나는 시기를 알 수 있습니다. 이 경우 워크플로 실행의 자동 추적을 제공하는 것은 간단합니다. 그림 8에서는 이 아이디어를 보여 줍니다.

그림 8: WF 런타임은 워크플로의 실행을 자동으로 추적할 수 있습니다.

이 예제에서 볼 수 있듯이 WF 런타임은 워크플로 실행 레코드를 추적 저장소에 쓸 수 있습니다. 한 가지 옵션은 활동이 시작되고 실행이 끝날 때마다 기록된 레코드를 사용하여 활동을 기록하는 것입니다. 예를 들어 그림에 표시된 순간 워크플로가 If 활동을 실행하기 시작하므로 WF 런타임에서 이를 나타내는 이벤트를 작성합니다. 워크플로 실행의 다양한 지점에서 해당 값을 기록하는 특정 변수(예: 워크플로 상태)를 추적할 수도 있습니다.

WF의 다른 측면과 마찬가지로, 이 자동 로깅은 기본적으로 개발자 쪽에서 작동하지 않아도 됩니다. 그는 단지 추적이 일어나야한다고 나타낼 수 있으며 관심있는 수준을 지정하고 WF는 나머지를 처리합니다.

재사용 가능한 사용자 지정 활동 만들기

WF의 BAL 활동은 다양한 유용한 기능을 제공합니다. 예를 들어, 이미 표시된 것처럼 이 기본 제공 집합에는 제어 흐름, 메시지 보내기 및 받기, 병렬 작업 수행 등에 대한 작업이 포함됩니다. 그러나 실제 애플리케이션을 빌드하려면 일반적으로 해당 애플리케이션과 관련된 작업을 수행하는 작업을 만들어야 합니다.

이를 가능하게 하기 위해 WF에서는 사용자 지정 활동을 만들 수 있습니다. 예를 들어 앞에서 보여 준 워크플로에서 X, Y 및 Z라는 레이블이 지정된 활동은 실제로 사용자 지정 활동입니다. 그림 9에서는 명시적으로 설명합니다.

그림 9: 사용자 지정 작업을 통해 워크플로가 애플리케이션별 작업을 수행할 수 있습니다.

사용자 지정 활동은 간단하거나 하나의 작업만 수행하거나 임의로 복잡한 논리를 포함하는 복합 작업일 수 있습니다. 단순하든 복잡하든 사용자 지정 활동은 다양한 방법으로 사용할 수 있습니다. 예를 들어 WF를 사용하여 만든 비즈니스 애플리케이션은 애플리케이션별 논리를 하나 이상의 사용자 지정 활동으로 구현할 수 있습니다. 또는 WF를 사용하는 소프트웨어 공급업체는 고객의 삶을 더 쉽게 만들기 위한 일련의 사용자 지정 활동을 제공할 수 있습니다. 예를 들어 Windows SharePoint Services를 사용하면 개발자가 SharePoint의 표준 목록을 통해 사용자와 상호 작용하는 WF 기반 애플리케이션을 만들 수 있습니다. 이 작업을 더 쉽게 수행할 수 있도록 SharePoint에는 목록에 정보를 쓰기 위한 사용자 지정 활동이 포함됩니다.

사용자 지정 작업은 C# 또는 Visual Basic 또는 다른 언어를 사용하여 코드로 직접 작성할 수 있습니다. 또한 몇 가지 흥미로운 옵션을 허용하는 기존 활동을 결합하여 만들 수도 있습니다. 예를 들어 조직은 가장 숙련된 개발자를 위한 낮은 수준의 사용자 지정 활동을 만든 다음, 기술 인력이 덜 사용할 수 있도록 상위 수준의 비즈니스 기능으로 패키지할 수 있습니다. 이러한 상위 수준 활동은 필요한 비즈니스 논리를 모두 재사용 가능한 상자에 깔끔하게 래핑하여 구현할 수 있습니다.

이에 대해 생각하는 또 다른 방법은 WF 런타임에서 실행되는 특정 활동 집합을 언어로 보는 것입니다. 조직에서 여러 애플리케이션에서 특정 문제를 해결하기 위해 재사용할 수 있는 사용자 지정 활동 그룹을 만드는 경우 실제로 수행하는 작업은 일종의 DSL(도메인별 언어)을 만드는 것입니다. 이 작업이 완료되면 덜 기술적인 사용자가 이러한 미리 패키지된 사용자 지정 기능 청크를 사용하여 WF 애플리케이션을 만들 수 있습니다. 애플리케이션의 기능을 구현하기 위해 새 코드를 작성하는 대신 기존 활동을 어셈블하여 유용한 새 소프트웨어를 만들 수 있습니다. 워크플로 방식으로 정의된 이 DSL 스타일은 경우에 따라 개발자 생산성을 크게 향상시킬 수 있습니다.

프로세스 표시

기존 프로그래밍 언어로 애플리케이션을 만드는 것은 코드를 작성하는 것을 의미합니다. WF를 사용하여 애플리케이션을 만드는 것은 일반적으로 그다지 낮은 수준이 아닙니다. 대신 적어도 워크플로의 기본 제어 흐름을 그래픽으로 어셈블할 수 있습니다. 이를 위해 WF에는 Visual Studio 내에서 실행되는 워크플로 디자이너가 포함됩니다. 그림 10은 예제를 보여 주는 예제입니다.

그림 10: Visual Studio 내에서 실행되는 워크플로 디자이너를 사용하면 개발자가 활동을 끌어서 놓아 워크플로를 만들 수 있습니다.

이 예제에서 볼 수 있듯이 WF 개발자가 사용할 수 있는 활동이 왼쪽에 나타납니다. 워크플로를 만들기 위해 디자인 화면에서 이러한 활동을 어셈블하여 애플리케이션에 필요한 논리를 만들 수 있습니다. 필요한 경우 다른 환경에서 WF 워크플로 디자이너를 다시 호스팅하여 다른 사용자가 자신의 제품 내에서 이 도구를 사용할 수 있도록 할 수 있습니다.

일부 개발자의 경우 이 그래픽 접근 방식을 통해 애플리케이션을 더 빠르고 쉽게 만들 수 있습니다. 또한 애플리케이션의 기본 논리를 더 잘 표시합니다. WF 워크플로 디자이너는 진행 중인 사항에 대한 간단한 그림을 제공하여 개발자가 애플리케이션의 구조를 보다 신속하게 이해할 수 있도록 도와줍니다. 이는 배포된 애플리케이션을 유지 관리해야 하는 사용자에게 특히 유용할 수 있습니다. 새 애플리케이션을 충분히 학습하면 시간이 많이 소요되는 프로세스가 될 수 있기 때문이다.

하지만 사용자 지정 활동은 어떨까요? 코드를 작성할 필요가 없나요? 대답은 '예'이므로 WF를 사용하면 Visual Studio를 사용하여 C#, Visual Basic 및 기타 언어로 사용자 지정 활동을 만들 수도 있습니다. 이 작업이 어떻게 작동하는지 파악하려면 WF 디자이너가 워크플로의 다양한 부분을 어떻게 나타내는지 이해하는 것이 중요합니다. 그림 11은 일반적으로 이 작업을 수행하는 방법을 보여줍니다.

그림 11: 워크플로의 상태 및 제어 흐름은 일반적으로 XAML에서 설명되지만 사용자 지정 작업은 코드로 작성할 수 있습니다.

WF 워크플로의 컴퍼지션(포함된 활동 및 해당 활동이 관련되는 방식)은 일반적으로 XAML(eXtensible Application Markup Language)을 사용하여 표현됩니다. 그림 11에서 알 수 있듯이 XAML은 워크플로의 상태를 변수로 설명하고 워크플로 활동 간의 관계를 표현하는 XML 기반 방법을 제공합니다. 예를 들어 여기서 가장 바깥쪽 워크플로 작업 시퀀스에 대한 XAML에는 예상한 대로 ReceiveMessage 작업 뒤에 If 활동이 포함됩니다.

이 경우 작업에 사용자 지정 활동 X 및 Y가 포함되어 있습니다. 그러나 이러한 활동은 XAML에서 만들어지는 것이 아니라 C# 클래스로 작성됩니다. XAML에서만 일부 사용자 지정 작업을 만들 수 있지만 보다 특수화된 논리는 일반적으로 코드로 직접 작성됩니다. 실제로 일반적인 방법은 아니지만 개발자는 코드로 워크플로를 자유롭게 작성할 수 있습니다. XAML을 사용하는 것은 반드시 필요한 것은 아닙니다.

Windows Workflow Foundation 사용: 일부 시나리오

WF의 메커니즘을 이해하는 것은 워크플로 방법을 파악하는 데 필수적인 부분입니다. 하지만 애플리케이션에서 워크플로를 사용하는 방법도 이해해야 합니다. 따라서 이 섹션에서는 몇 가지 일반적인 상황에서 WF를 사용하는 방법과 이유에 대해 아키텍처를 살펴봅니다.

워크플로 서비스 만들기

비즈니스 논리를 서비스로 빌드하는 것은 종종 의미가 있습니다. 예를 들어 브라우저에서 ASP.NET, Silverlight 클라이언트 및 독립 실행형 데스크톱 애플리케이션에서 동일한 기능 집합에 액세스해야 한다고 가정합니다. 이러한 클라이언트, 즉 서비스로 호출할 수 있는 작업 집합으로 이 논리를 구현하는 것이 가장 좋은 방법입니다. 또한 논리를 서비스로 노출하면 다른 논리에 액세스할 수 있으므로 애플리케이션 통합이 더 쉬워질 수 있습니다. (이것은 SOA, 서비스 지향 아키텍처의 개념 뒤에 핵심 아이디어입니다.)

오늘날 .NET 개발자에게 서비스를 만들기 위한 주력 기술은 WCF(Windows Communication Foundation)입니다. 무엇보다도 WCF를 통해 개발자는 REST, SOAP 및 기타 통신 스타일을 사용하여 액세스할 수 있는 비즈니스 논리를 구현할 수 있습니다. 그리고 일부 서비스의 경우 WCF가 필요한 모든 것이 될 수 있습니다. 각 작업이 단독으로 있는 서비스를 구현하는 경우(예: 필요한 순서 없이 언제든지 모든 작업을 호출할 수 있음) 이러한 서비스를 원시 WCF 서비스로 빌드하는 것은 괜찮습니다. 예를 들어 작업에서 데이터만 노출하는 서비스의 작성자는 WCF를 사용하는 것만으로 도망가는 것이 좋습니다.

그러나 서비스의 작업이 관련 기능 집합을 구현하는 더 복잡한 상황에서는 WCF만으로는 충분하지 않을 수 있습니다. 고객이 항공편 예약을 예약하거나 온라인 쇼핑을 하거나 다른 비즈니스 프로세스를 수행할 수 있는 애플리케이션에 대해 생각해 보세요. 이와 같은 경우 WF를 사용하여 서비스의 논리를 구현하도록 선택할 수 있습니다. 이 조합에는 이름이 있습니다. WF를 사용하여 구현되고 WCF를 통해 노출되는 논리를 워크플로 서비스라고 합니다. 그림 12에서는 아이디어를 보여 줍니다.

그림 12: 워크플로 서비스는 WCF를 사용하여 WF 기반 논리를 노출합니다.

그림에서 볼 수 있듯이 WCF에서는 클라이언트가 SOAP, REST 또는 다른 항목을 통해 호출할 수 있는 하나 이상의 엔드포인트를 노출할 수 있습니다. 클라이언트가 이 예제 서비스에서 초기 작업을 호출할 때 요청은 워크플로의 첫 번째 ReceiveMessage 작업에 의해 처리됩니다. If 활동이 다음에 나타나고 포함된 사용자 지정 활동 중 실행되는 작업은 클라이언트 요청의 내용에 따라 달라집니다. If가 완료되면 SendMessage를 통해 응답이 반환됩니다. 다른 작업을 호출하는 클라이언트의 두 번째 요청은 비슷한 방식으로 처리됩니다. 이는 ReceiveMessage에서 수락되고 워크플로 논리에 의해 처리된 다음 SendMessage를 사용하여 응답됩니다.

서비스 지향 비즈니스 논리를 이런 식으로 빌드하는 것이 좋은 이유는 무엇인가요? 대답은 분명하다: 그것은 통합 및 확장 가능한 애플리케이션을 만들 수 있습니다. 모든 작업에 검사를 포함하도록 요구하는 대신 지금 바로 저를 호출하는 것이 합법적인가요?-이 지식은 워크플로 논리 자체에 포함됩니다. 이렇게 하면 애플리케이션을 더 쉽게 작성할 수 있으며, 중요한 것처럼 최종적으로 유지 관리해야 하는 사람들에게 더 쉽게 이해할 수 있습니다. 또한 WF 런타임은 확장성 및 상태 관리를 처리하기 위해 사용자 고유의 코드를 작성하는 대신 이러한 작업을 수행합니다.

워크플로 서비스는 다른 WF 애플리케이션과 마찬가지로 앞에서 설명한 모든 이점을 가져옵니다. 여기에는 다음이 포함되었습니다.

병렬 작업을 수행하는 서비스를 구현하는 것은 간단합니다. 작업을 병렬 작업으로 삭제하기만 하면 됩니다.
추적은 런타임에서 제공합니다.
문제 도메인에 따라 다른 서비스에서 사용할 재사용 가능한 사용자 지정 활동을 만들 수 있습니다.
WF 워크플로 디자이너에 직접 표시되는 프로세스 논리를 사용하여 워크플로를 그래픽으로 만들 수 있습니다.

이전 버전의 WF에서는 이와 같이 WF와 WCF를 함께 사용하여 워크플로 서비스를 만드는 것이 그리 쉽지 않았습니다. .NET Framework 4를 사용하면 이 기술 조합이 좀 더 자연스러운 방식으로 결합됩니다. 목표는 이 스타일의 비즈니스 논리를 가능한 한 간단하게 만드는 것입니다.

"더블린"을 사용하여 워크플로 서비스 실행

워크플로의 한 가지 큰 문제는 아직 논의되지 않았습니다. 여기서 실행되나요? WF 런타임은 활동과 마찬가지로 클래스입니다. 이러한 모든 작업은 일부 호스트 프로세스에서 실행되어야 하지만 이 프로세스는 무엇인가요?

대답은 WF 워크플로가 거의 모든 프로세스에서 실행될 수 있다는 것입니다. 원하는 경우 WF의 기본 서비스 중 일부(예: 지속성)를 대체하여 사용자 고유의 호스트를 자유롭게 만들 수 있습니다. 많은 조직, 특히 소프트웨어 공급업체에서 이 작업을 수행했습니다. 그러나 관리 기능을 갖춘 WF에 대한 진정한 기능의 호스트 프로세스를 구축하는 것은 세계에서 가장 간단한 일이 아닙니다. 인프라가 아닌 비즈니스 논리를 구축하는 데 비용을 지출하려는 조직의 경우 이러한 노력을 피하는 것이 좋습니다.

더 간단한 옵션은 IIS(인터넷 정보 서버)에서 제공하는 작업자 프로세스에서 WF 워크플로를 호스트하는 것입니다. 이 작업은 작동하지만 베어본 솔루션만 제공합니다. WF 개발자의 삶을 더 쉽게 만들기 위해 Microsoft는 "더블린"이라는 기술 코드를 제공하고 있습니다. IIS 및 WAS(Windows 프로세스 정품 인증 서비스)에 대한 확장으로 구현되는 "더블린"의 주요 목표는 IIS 및 WAS를 워크플로 서비스의 호스트로 더 매력적으로 만드는 것입니다. 그림 13은 워크플로 서비스가 "더블린" 환경에서 실행되는 방식을 보여 줍니다.

그림 13: "더블린"은 워크플로 서비스에 대한 관리 등을 제공합니다.

WF 자체에는 워크플로의 상태, 추적 등을 유지하기 위한 메커니즘이 포함되어 있지만 기본 사항만 제공합니다. "더블린"은 보다 완전하게 유용하고 관리하기 쉬운 환경을 제공하기 위해 WF의 내장 지원을 기반으로 합니다. 예를 들어 SQL Server 기반 지속성 저장소 및 추적 저장소와 함께 "더블린"은 이러한 저장소를 사용하기 위한 관리 도구를 제공합니다. IIS 관리자에 대한 확장으로 구현된 이 도구를 사용하면 사용자가 지속형 워크플로(예: 종료)를 검사 및 관리하고, 추적이 수행되는 정도를 제어하고, 추적 로그를 검사하는 등의 작업을 수행할 수 있습니다.

"더블린"은 WF의 기존 기능에 추가된 기능과 함께 다른 서비스도 추가합니다. 예를 들어 "Dublin"은 실행 중인 워크플로 인스턴스를 모니터링하여 실패한 모든 인스턴스를 자동으로 다시 시작할 수 있습니다. "더블린"에 대한 Microsoft의 주요 목표는 분명합니다. IIS/WAS에서 호스트되는 워크플로 서비스를 관리하고 모니터링하기 위한 유용한 도구 및 인프라 집합을 제공합니다.

ASP.NET 애플리케이션에서 워크플로 서비스 사용

대부분의 .NET 애플리케이션이 ASP.NET 사용한다고 가정해 보겠습니다. 워크플로를 주류로 만드는 것은 WF를 ASP.NET 개발자에게 매력적인 옵션으로 만드는 것을 의미합니다.

이전 버전의 WF에서는 많은 수의 ASP.NET 애플리케이션에 대해 워크플로 성능이 충분하지 않았습니다. 그러나 .NET Framework 4 릴리스의 경우 WF의 디자이너는 기술의 중요한 부분을 다시 설계하여 성능을 크게 향상시켰습니다. 이 릴리스는 "더블린"의 출현과 함께 WF 기반 애플리케이션, 특히 워크플로 서비스를 ASP.NET 개발자에게 더 실행 가능한 옵션으로 만듭니다. 그림 14는 이 모양에 대한 간단한 그림을 보여줍니다.

그림 14: ASP.NET 애플리케이션의 비즈니스 논리를 워크플로 서비스로 구현할 수

이 시나리오에서 ASP.NET 페이지는 애플리케이션의 사용자 인터페이스만 구현합니다. 해당 논리는 워크플로 서비스에서 전적으로 구현됩니다. 워크플로 서비스에 ASP.NET 애플리케이션은 다른 클라이언트일 뿐이며 ASP.NET 애플리케이션에서는 워크플로 서비스가 다른 서비스와 같이 표시됩니다. 이 서비스는 WF 및 WCF를 사용하여 구현된다는 사실을 알아야 합니다.

다시 한번, 그래도, 큰 질문은, 왜이 작업을 수행 할 것인가? ASP.NET 애플리케이션의 논리를 일반적인 방식으로 작성하는 것은 어떨까요? WF(및 WCF)를 사용하면 무엇을 구매하나요? 이 시점에서, 그 질문에 대한 답변의 대부분은 아마 분명하지만, 그들은 여전히 반복 가치가있다 :

애플리케이션의 논리를 여러 ASP.NET 페이지에 분산하는 대신 단일 통합 워크플로 내에서 해당 논리를 구현할 수 있습니다. 특히 큰 사이트의 경우 애플리케이션을 훨씬 쉽게 빌드하고 유지 관리할 수 있습니다.
개발자는 세션 개체 또는 다른 항목을 사용하여 ASP.NET 애플리케이션의 상태를 명시적으로 사용하는 대신 WF 런타임을 사용하여 이 작업을 수행할 수 있습니다. ASP.NET 애플리케이션은 쿠키에 저장하는 등 각 워크플로 인스턴스(사용자당 하나일 가능성이 높음)에 대한 인스턴스 식별자만 추적하면 됩니다. 애플리케이션이 이 식별자를 "Dublin"에 제공하면 워크플로 인스턴스가 자동으로 다시 로드됩니다. 그런 다음 모든 상태가 복원된 상태로 중단된 위치에서 실행을 시작합니다.
더 쉬운 병렬 처리, 기본 제공 추적, 재사용 가능한 활동의 가능성 및 애플리케이션의 논리를 시각화하는 기능을 포함하여 WF의 다른 이점도 적용됩니다.

워크플로 서비스는 특정 컴퓨터의 특정 프로세스에 연결되지 않으므로 여러 "더블린" 인스턴스에서 부하를 분산할 수 있습니다. 그림 15는 이 모양에 대한 예제를 보여 있습니다.

그림 15: 복제된 ASP.NET 애플리케이션은 여러 "더블린" 인스턴스를 사용하여 워크플로 서비스를 실행할 수 있습니다.

이 간단한 시나리오에서는 ASP.NET 애플리케이션의 페이지가 세 개의 IIS 서버 컴퓨터에서 복제됩니다. 이러한 페이지는 사용자와의 상호 작용을 처리하지만 애플리케이션의 비즈니스 논리는 "Dublin"으로 실행되는 워크플로 서비스로 구현됩니다. "더블린" 환경의 두 인스턴스가 각각 자체 머신에서 실행되고 있습니다. 사용자의 첫 번째 요청이 들어오면 부하 분산 장치는 이를 IIS의 최상위 인스턴스로 라우팅합니다. 이 요청을 처리하는 ASP.NET 페이지에서는 이 비즈니스 논리 청크를 구현하는 워크플로 서비스에서 작업을 호출합니다. 이로 인해 WF 워크플로가 그림의 맨 위에 있는 "더블린" 인스턴스에서 실행되기 시작합니다. 이 워크플로의 관련 활동이 완료되면 호출이 ASP.NET 페이지로 반환되고 워크플로가 유지됩니다.

사용자의 두 번째 요청은 다른 IIS 인스턴스로 라우팅됩니다. 이 컴퓨터의 ASP.NET 페이지는 첫 번째 요청을 처리한 컴퓨터와 다른 컴퓨터의 (지속형) 워크플로에서 작업을 호출합니다. "더블린"은 동료 서버와 공유하는 지속성 저장소에서 워크플로 인스턴스를 로드하기만 하면 됩니다. 다시 로드된 이 워크플로 서비스는 사용자의 요청을 처리하여 중단된 위치를 선택합니다.

WF(및 WCF)를 이해한 다음, 이 새로운 스타일에서 논리를 만드는 방법을 배우려면 몇 가지 작업이 필요합니다. 간단한 ASP.NET 애플리케이션의 경우 이 학습 곡선을 오르는 것은 필요한 노력의 가치가 없을 수 있습니다. 그러나 .NET을 사용하여 더 큰 웹 애플리케이션을 만드는 사람은 적어도 해당 논리를 워크플로 서비스로 만들 가능성을 고려해야 합니다.

클라이언트 애플리케이션에서 워크플로 사용

지금까지는 전적으로 WF를 사용하여 서버 애플리케이션을 만드는 데 중점을 두어 왔습니다. 그러나 이 기술이 오늘날 가장 자주 사용되는 방법이지만, WF는 클라이언트 애플리케이션에도 도움이 될 수 있습니다. 일반적으로 클라이언트 머신에서 실행되는 코드는 많은 동시 사용자를 처리할 필요가 없지만 WF는 여전히 사용할 수 있으므로 확장성 측면은 일반적으로 많이 추가되지 않습니다.

예를 들어 Windows Forms 또는 Windows Presentation Foundation을 사용하여 만든 그래픽 인터페이스를 사용자에게 제공하는 클라이언트 애플리케이션을 생각해 보세요. 애플리케이션에는 사용자의 마우스 클릭을 처리하는 이벤트 처리기가 있을 수 있으며, 이러한 이벤트 처리기에 비즈니스 논리가 분산될 수 있습니다. 이는 별도의 페이지 그룹에 논리를 분산하는 ASP.NET 애플리케이션과 매우 유사하며 동일한 문제를 만들 수 있습니다. 예를 들어 애플리케이션의 흐름은 식별하기 어려울 수 있으며, 개발자는 올바른 순서로 작업을 수행하는지 확인하기 위해 검사를 삽입해야 할 수 있습니다. ASP.NET 애플리케이션과 마찬가지로 이 논리를 통합 WF 워크플로로 구현하면 이러한 문제를 해결하는 데 도움이 될 수 있습니다.

WF의 다른 측면도 클라이언트에서 유용할 수 있습니다. 예를 들어 애플리케이션이 여러 백 엔드 웹 서비스를 병렬로 호출해야 하거나 추적을 활용할 수 있다고 가정합니다. 서버에서와 마찬가지로 WF는 이러한 문제를 해결하는 데 도움이 될 수 있습니다. 오늘날 대부분의 WF 애플리케이션은 서버에서 실행되지만 이것이 유일한 선택은 아니라는 것을 인식하는 것이 중요합니다.

자세히 살펴보기: Windows Workflow Foundation의 기술

이 개요의 목표는 WF 개발자로 만드는 것이 아닙니다. 그럼에도 불구하고 WF의 기술에 대해 조금 더 알고 있으면 워크플로 방법을 선택하는 것이 적합한 시기를 결정하는 데 도움이 될 수 있습니다. 따라서 이 섹션에서는 WF의 가장 중요한 부분 중 일부를 자세히 살펴봅합니다.

워크플로 종류

.NET Framework 4에서 WF 개발자는 일반적으로 서로 다른 가장 바깥쪽 작업을 선택하여 두 가지 워크플로 스타일 중에서 선택합니다. 이러한 활동은 다음과 같습니다.

시퀀스: 작업을 순서대로 실행합니다. 시퀀스에는 If 활동, While 활동 및 기타 종류의 제어 흐름이 포함될 수 있습니다. 뒤로 이동할 수 없습니다. 그러나 실행은 항상 앞으로 이동해야 합니다.
순서도: 시퀀스처럼 작업을 하나씩 실행하지만 컨트롤이 이전 단계로 돌아갈 수도 있습니다. .NET Framework 4 WF 릴리스의 새로운 이 보다 유연한 접근 방식은 실제 프로세스의 작동 방식과 대부분의 생각 방식에 더 가깝습니다.

시퀀스 및 순서도는 워크플로에서 가장 바깥쪽 활동으로 작동할 수 있지만 워크플로 내에서도 사용할 수 있습니다. 이렇게 하면 이러한 복합 활동을 임의의 방식으로 중첩할 수 있습니다.

처음 두 릴리스에서 WF는 상태 머신이라는 워크플로의 가장 바깥쪽 작업에 대한 또 다른 옵션도 포함했습니다. 이름에서 알 수 있듯이 이 작업을 통해 개발자는 명시적으로 상태 머신을 만든 다음 해당 상태 머신에서 외부 이벤트가 활동을 트리거하도록 할 수 있습니다. 그러나 .NET Framework 4의 WF는 이전 릴리스에서 대부분의 활동을 다시 작성하고 새 디자이너를 빌드해야 하는 큰 변화입니다. 관련 작업으로 인해 WF의 작성자는 초기 .NET Framework 4 릴리스에서 State Machine 작업을 제공하지 않습니다. (Microsoft의 리소스조차도 제한이 없습니다.) 그러나 새 순서도 작업은 이전에 State Machine을 사용해야 하는 많은 상황을 해결해야 합니다.

기본 작업 라이브러리

워크플로에는 개발자가 사용하도록 선택한 모든 활동 집합이 포함될 수 있습니다. 예를 들어 워크플로에 사용자 지정 활동만 포함하는 것은 전적으로 합법적입니다. 여전히, 이것은 매우 가능성이 없습니다. 대부분의 경우 WF 워크플로는 기본 활동 라이브러리에 제공된 것 중 적어도 일부를 사용합니다. .NET Framework 4에서 WF에서 제공하는 보다 광범위하게 유용한 BAL 활동 중에는 다음과 같습니다.

할당: 워크플로의 변수에 값을 할당합니다.
보정: 장기 실행 트랜잭션에서 발생하는 문제를 처리하는 것과 같은 보상을 수행하는 방법을 제공합니다.
DoWhile: 활동을 실행한 다음 조건을 확인합니다. 조건이 true인 한 작업이 반복해서 실행됩니다.
순서도: 순차적으로 실행되는 활동 집합을 그룹화하지만 컨트롤이 이전 단계로 돌아갈 수도 있습니다.
ForEach: 컬렉션의 각 개체에 대한 작업을 실행합니다.
If: 실행 분기를 만듭니다.
병렬: 동시에 여러 활동을 실행합니다.
지속: 워크플로를 유지하기 위해 WF 런타임을 명시적으로 요청합니다.
선택: 이벤트 집합을 기다린 다음 첫 번째 이벤트와 연결된 활동만 실행할 수 있습니다.
ReceiveMessage: WCF를 통해 메시지를 받습니다.
SendMessage: WCF를 통해 메시지를 보냅니다.
시퀀스: 순차적으로 실행되는 활동 집합을 그룹화합니다. 시퀀스는 워크플로의 가장 바깥쪽 작업으로 작동하는 것과 함께 워크플로 내에서도 유용합니다. 예를 들어 While 활동에는 다른 하나의 활동만 포함될 수 있습니다. 해당 작업이 Sequence인 경우 개발자는 while 루프 내에서 임의의 수의 활동을 실행할 수 있습니다.
Switch: 실행의 다방향 분기를 제공합니다.
Throw: 예외를 발생합니다.
TryCatch: 예외를 처리하는 try/catch 블록을 만들 수 있습니다.
While: true 조건만큼 단일 작업을 실행합니다.

전체 목록이 아닙니다. .NET Framework 4의 WF에는 더 많은 항목이 포함되어 있습니다. 또한 Microsoft는 오픈 소스 프로젝트를 위한 호스팅 사이트인 CodePlex에서 새로운 WF 활동을 사용할 수 있도록 할 계획입니다. 예를 들어 .NET Framework 4 릴리스 직후 워크플로에서 데이터베이스 쿼리 및 업데이트를 실행하고 PowerShell 명령을 실행할 수 있는 활동을 찾습니다.

이 목록에서 알 수 있듯이 BAL은 일반적으로 기존의 범용 프로그래밍 언어의 기능을 반영합니다. WF는 범용 기술이므로 놀라운 일이 아닙니다. 그러나 이 개요에서 설명한 것처럼, WF 런타임에서 실행되는 활동과 같은 접근 방식은 애플리케이션 개발자의 삶을 더 좋게 만들 수 있습니다.

.NET Framework 4의 워크플로

.NET Framework 릴리스 4는 Windows Workflow Foundation에 중요한 변경 내용을 제공합니다. 예를 들어 BAL의 활동이 다시 작성되었으며 일부 새 작업이 추가되었습니다. 예를 들어 많은 워크플로가 훨씬 더 빠르게 실행되는 등 실질적인 이점을 제공하지만 이전 버전의 WF를 사용하여 만든 워크플로를 .NET 4 버전의 WF 런타임에서 실행할 수 없다는 의미이기도 합니다. 이러한 이전 워크플로는 .NET Framework 4 워크플로와 함께 계속 실행할 수 있지만, 삭제할 필요는 없습니다. 또한 전체 워크플로를 포함하여 이전 버전의 WF를 사용하여 만든 활동은 .NET Framework 4에서 WF가 제공하는 새 Interop 작업 내에서 실행될 수 있습니다. 이렇게 하면 이전 워크플로의 논리를 새 워크플로에서 사용할 수 있습니다.

더 나은 성능과 함께, WF의 새로운 릴리스는 또한 다른 흥미로운 변화를 제공합니다. 예를 들어 이전 버전의 WF에는 임의의 코드를 포함할 수 있는 코드 작업이 포함되어 있습니다. 이렇게 하면 개발자가 워크플로에 원하는 기능을 거의 추가할 수 있지만 약간 우아하지 않은 솔루션이었습니다. .NET Framework 4에서 WF의 작성자는 사용자 지정 활동을 훨씬 더 간단하게 작성하므로 코드 작업이 제거되었습니다. 이제 새 기능이 사용자 지정 작업으로 만들어집니다.

.NET Framework 4 릴리스의 변경 내용은 2006년 WF가 처음 등장한 이후 가장 큰 변화입니다. 그러나 개발자가 워크플로를 사용하여 효과적인 애플리케이션을 쉽게 빌드할 수 있도록 하는 동일한 목표를 가지고 있습니다.

결론

Windows Workflow Foundation은 많은 애플리케이션에 실질적인 이점을 제공합니다. 첫 번째 릴리스에서 WF는 주로 소프트웨어 공급업체와 화음을 일으켰습니다. 이 기술의 원래 화신은 유용했지만 주류 기업 사용에는 적합하지 않았습니다. .NET Framework 4를 사용하면 WF 작성자가 이를 변경하려고 합니다.

WF와 WCF가 잘 작동하고, WF의 성능을 개선하고, 더 나은 워크플로 디자이너를 제공하고, "더블린"과 함께 완전한 기능을 갖춘 호스트 프로세스를 제공함으로써 Microsoft는 광범위한 시나리오에서 워크플로를 더욱 매력적으로 만들고 있습니다. Windows 애플리케이션 개발 드라마의 전문 플레이어로서의 시대가 막을 내립니다. WF는 중앙 무대에 가는 중입니다.

작성자 정보

데이비드 샤펠은 캘리포니아 주 샌프란시스코에 있는 샤펠 & 어소시에이츠 수석 . 그는 말하기, 쓰기 및 컨설팅을 통해 전 세계 사람들이 새로운 기술에 대해 더 잘 이해하고, 사용하고, 더 나은 결정을 내릴 수 있도록 도와줍니다.

다음을 통해 공유