ASP.NET 프로그램 개발에 WWF 사용

소개

WWF를 사용하면 프로세서 흐름 기반 워크플로를 생성하고 이를 모든 유형의 .NET 애플리케이션에 배포할 수 있습니다. 또한 이 문서에서는 ASP.NET 개발자가 직면한 몇 가지 고유한 문제, 즉 상태 유지 및 페이지 탐색과 같이 워크플로를 사용하여 해결할 수 있는 문제에 대해 설명합니다.

2005년 9월 Microsoft는 2년마다 열리는 전문 개발자 컨퍼런스에서 Windows Workflow Foundation(WWF, Windows Workflow Foundation)을 공개했습니다. WinFX API의 핵심 중 하나인 WWF는 개발자에게 프로세스 중심 및 워크플로 중심 애플리케이션을 개발할 수 있는 공통 프레임워크를 제공합니다.

현재 일부 조직에서는 전체 비즈니스 프로세스를 자동화하려고 노력하고 있습니다. 표준적인 대답은 개발자 팀을 구성하여 해당 코드를 개발하는 것입니다. 이 접근 방식은 이러한 조직에 적합하지만 몇 가지 고유한 문제가 있습니다. 이 문제를 심층적으로 이해하려면 워크플로의 기본 특성을 이해해야 합니다.

워크플로는 기본적으로 작업 단위를 완료하는 데 관련된 활동을 보관하는 방법입니다. 일반적으로 처리 중에 작업은 하나 이상의 활동을 통해 "흐름"됩니다. 이러한 활동은 기계나 사람에 의해 수행될 수 있으며 인터넷 애플리케이션에서 페이지 순서를 정의하는 것처럼 간단할 수도 있고 많은 사람이 보고 변경하고 승인해야 하는 문서나 제품을 관리하는 것처럼 복잡할 수도 있습니다. 복잡한.

너무 많은 워크플로에서는 사람의 개입이 허용되어야 하기 때문에 완료하는 데 몇 시간에서 몇 달 이상까지 오랜 시간이 걸릴 수 있습니다. 예를 들어 프로세스에 참여하는 사람이 부재중이거나 현지에 있지 않거나 다른 작업으로 바쁘기 때문에 워크플로는 모든 비활성 기간 동안 자체적으로 지속될 수 있어야 합니다. 더욱이 코딩을 통해 독립적으로 구현되는 프로세스는 기술자가 아닌 사람이 이해하기 어렵고 개발자가 변경하기 어려울 수 있습니다. 이러한 요소와 기타 요소는 Windows WF와 같은 일반 워크플로 프레임워크의 목표입니다. 이 프레임워크는 시각적 인터페이스를 제공하거나 실현된 공통 API 세트를 정의하여 워크플로를 더 쉽게 생성, 변경 및 관리할 수 있도록 하는 것을 목표로 합니다.

Windows Forms, 콘솔 애플리케이션, Windows 서비스 및 ASP.NET 웹 애플리케이션을 포함한 모든 유형의 .NET 애플리케이션에 WWF 워크플로를 배치할 수 있습니다. 각 유형마다 특별한 고려 사항이 필요합니다. 일부 기존 예제는 Windows Forms 및 콘솔 응용 프로그램에 워크플로를 호스팅하는 방법을 설명하기에 충분하지만 이 문서에서는 워크플로를 자신의 응용 프로그램에 통합하려는 ASP.NET 개발자가 직면한 문제에 중점을 둘 것입니다.

작성자 참고 사항: 이 문서에 제공된 코드는 Windows WF Beta 1 및 Visual Studio 2005 Beta 2를 사용하여 작성되었습니다. www.windowsworkflow.net 에서 Windows WF 설치에 대한 정보를 찾을 수 있습니다. 이 문서에서는 Windows WF의 기본 사항 중 일부를 설명하지만 이 영역에서 사용할 수 있는 다른 리소스도 있습니다. 나는 독자가 Windows WF에 대해 최소한 어느 정도 알고 있다고 가정합니다. 이 기사의 목적은 Windows WF를 높은 수준에서 논의하기보다는 Windows WF 및 ASP.NET을 심층적으로 분석하는 것입니다.

1. Windows WF 및 MVC 패턴

ASP.NET 애플리케이션을 개발할 때 WWF를 사용하는 일반적인 방법은 MVC(모델-뷰-컨트롤러) 접근 방식을 구현하는 것입니다. 본질적으로 MVC의 목표는 프레젠테이션 계층, 애플리케이션 로직, 애플리케이션 흐름 로직을 분리하는 것입니다.

이를 이해하면 ASP.NET 응용 프로그램을 개발할 때 매우 도움이 될 것입니다. 헬프 데스크 티켓 워크플로 장소를 고려해 보십시오. 비즈니스 사용자가 ASP.NET 웹 양식을 작성하고 제출 버튼을 클릭하여 이 워크플로를 시작한다고 가정합니다. 다음으로, 서버는 Windows Forms 응용 프로그램과 헬프 데스크를 사용하는 직원에게 "새 티켓을 사용할 수 있습니다"라고 알립니다. 그런 다음 헬프 데스크 직원이 문제를 해결하고 최종적으로 티켓을 종료합니다. Windows WF를 사용하여 이 워크플로 시나리오를 개발하는 경우 모든 처리 논리와 흐름이 워크플로 자체에 포함될 수 있으며 ASP.NET 응용 프로그램은 이 논리를 전혀 이해할 필요가 없습니다.

이런 종류의 장소는 확실한 증거를 제공합니다. 설명과 논리를 분리하는 것이 좋습니다. 헬프 데스크 요청을 처리하는 이 프로세스는 매우 평범하기 때문에 C# 또는 VB.NET 코드를 사용하여 여러 다른 .NET 애플리케이션에서 이 논리를 구현하는 경우 코딩이 중복되거나 더 나쁜 위험이 있습니다. 완전히 다른 코드 리드를 사용하면 됩니다. 동일한 비즈니스 프로세스를 다르게 구현합니다. 그러나 WWF를 사용하여 이 프로세스를 구현하는 경우 이 프로세스가 필요한 애플리케이션 개발자는 애플리케이션 로직 변경에 대해 걱정할 필요 없이 한 곳, 즉 워크플로 자체에서 단계만 수정하면 됩니다. 코드 복제와 이 프로세스를 구현할 위치는 Windows WF를 사용하면 쉽게 수행할 수 있습니다.

Windows WF를 사용하여 ASP.NET에서 MVC 아키텍처를 구현할 때 개발자는 워크플로가 여전히 애플리케이션 내에서 호스팅되는 동안 애플리케이션과 독립적인 워크플로를 구축해야 합니다. 이는 설명과 독립적인 논리를 유지하고 작업 단계의 순서와 웹 애플리케이션의 페이지 흐름 간에 높은 수준의 독립성을 유지하는 데 도움이 됩니다.

새로운 WWF 개발자는 특정 순서에 따라 고정된 수의 활동이 포함된 워크플로를 개발한 다음 동일한 순서에 따라 한 양식에서 다른 양식으로 흐르는 ASP.NET 웹 양식 집합을 개발하려고 할 수 있습니다. 안타깝게도 이는 논리적인 것처럼 보이지만 워크플로 논리를 다시 구현하게 되므로 실제로는 매우 비생산적입니다. 웹 페이지 X는 이 워크플로 단계를 올바르게 구현하기 위해 페이지 Y 또는 페이지 Z로 이동해야 하는지 알 필요가 없습니다. 대신, 워크플로(모델)는 ASP.NET(컨트롤러)에게 다음에 수행할 작업을 알려주어야 하며, 그런 다음 ASP.NET은 표시할 페이지를 결정해야 합니다. 이런 방식으로 각 페이지는 전체 프로세스를 거의 이해하지 않아도 됩니다. 단지 다른 활동을 완료하는 방법을 알고 워크플로우가 페이지가 한 위치에서 다른 위치로 흐르는 방식을 처리하도록 하면 됩니다. 이러한 분리는 개발자에게 페이지 흐름을 처리할 때 상당한 유연성을 제공합니다. 예를 들어, 페이지가 표시되는 순서를 변경하기로 결정한 경우 ASP.NET 응용 프로그램에서 코드 한 줄을 변경하지 않고도 워크플로 내에서 이 작업을 쉽게 수행할 수 있습니다.

2. 간단한 작업 흐름 MVC 예제

이 아이디어를 설명하기 위해 간단한 ASP.NET 응용 프로그램과 작업 흐름을 보여 드리겠습니다. 지나치게 단순화된 이 워크플로는 외부 애플리케이션에서 일부 개인 정보를 수집한 다음 이를 표시하는 프로세스를 설명합니다. 단계는 다음과 같습니다.

1. 메서드 호출 - 이는 사람의 이름을 요청하는 것을 의미합니다. 이 워크플로는 InvokeMethod 활동을 사용합니다(그림 1 참조).

2. 이벤트가 발생할 때까지 기다립니다. 이는 이 단계에서 이름을 수신한다는 의미이며 워크플로는 EventSink 활동을 사용합니다.

3. 유사한 전화를 사용하여 호스트로부터 이메일 주소를 얻습니다.

4. 이벤트를 기다린다는 것은 주소를 받는 것을 의미합니다.

5. 이름과 이메일을 받은 후 워크플로는 InvokeMethod 활동을 시작하여 개인 정보를 호출 애플리케이션으로 보냅니다. 실제 상황에서는 이 마지막 단계가 그다지 중요하지 않습니다. 아마도 웹 서비스를 호출하여 데이터를 다른 시스템으로 보내거나 데이터베이스에 넣을 것입니다.

그림 1. 샘플 워크플로: 이 워크플로는 샘플 ASP.NET 애플리케이션에 내재된 프로세스를 설명합니다.