다음을 통해 공유

워크플로 호스팅 옵션

대부분의 WF(Windows Workflow Foundation) 샘플은 콘솔 애플리케이션에서 호스트되는 워크플로를 사용하지만 실제 워크플로에 대한 현실적인 시나리오는 아닙니다. 실제 비즈니스 애플리케이션의 워크플로는 개발자가 작성한 Windows 서비스 또는 IIS 7.0 또는 AppFabric과 같은 서버 애플리케이션과 같은 영구 프로세스에서 호스트됩니다. 이러한 방법 간의 차이점은 다음과 같습니다.

Windows AppFabric을 사용하여 IIS에서 워크플로 호스팅

AppFabric에서 IIS를 사용하는 것이 워크플로의 기본 호스트입니다. AppFabric을 사용하는 워크플로에 대한 호스트 애플리케이션은 IIS를 통한 HTTP에 대한 종속성을 제거하는 Windows 정품 인증 서비스입니다.

IIS에서만 워크플로 호스팅

실행 중인 애플리케이션의 유지 관리를 용이하게 하는 AppFabric에서 사용할 수 있는 관리 및 모니터링 도구가 있으므로 IIS 7.0만 사용하는 것은 권장되지 않습니다. AppFabric으로 이동하는 데 인프라 문제가 있는 경우에만 워크플로를 IIS 7.0에서만 호스팅해야 합니다.

경고

IIS 7.0은 다양한 이유로 애플리케이션 풀을 주기적으로 재활용합니다. 애플리케이션 풀이 재활용되면 IIS는 이전 풀에 대한 메시지 수락을 중지하고 새 애플리케이션 풀을 인스턴스화하여 새 요청을 수락합니다. 응답을 보낸 후 워크플로가 계속 작동하는 경우 IIS 7.0은 수행 중인 작업을 인식하지 못하며 호스팅 애플리케이션 풀을 재활용할 수 있습니다. 이 경우 워크플로가 중단되고 추적 서비스는 빈 이유 필드가 있는 1004 - WorkflowInstanceAborted 메시지를 기록합니다.

지속성을 사용하는 경우 호스트는 마지막 지속성 지점에서 중단된 인스턴스를 명시적으로 다시 시작해야 합니다.

AppFabric을 사용하는 경우 지속성을 사용하는 경우 워크플로 관리 서비스는 결국 마지막으로 성공한 지속성 지점에서 워크플로를 다시 시작합니다. 지속성이 사용되지 않고 워크플로가 요청/응답 패턴 외부에서 작업을 수행하는 경우 워크플로가 중단되면 데이터가 손실됩니다.

사용자 지정 Windows 서비스에서 워크플로 호스팅

워크플로를 호스트하는 사용자 지정 워크플로 서비스를 만들려면 개발자가 AppFabric에서 기본적으로 제공하는 많은 기능을 복제해야 하지만 사용자 지정 기능을 통해 더 많은 유연성을 허용합니다. 이 옵션은 AppFabric이 옵션이 아닌 것으로 판명된 경우에만 고려해야 합니다.