Windows Workflow Foundation에 대한 경험은 어떻습니까?

StackOverflow https://stackoverflow.com/questions/115124

문제

저는 웹상의 LOB(기간 업무) 응용 프로그램에 사용할 WF를 평가하고 있으며, 이 기술에 대한 최근 직접적인 설명을 듣고 싶습니다.

여기서 나의 주요 관심은 프로젝트의 유지 관리 가능성을 향상시키는 것이며, 자주 변경되는 복잡한 프로세스에서 작업할 때 개발자 생산성을 높이는 것입니다.

저는 WF의 아이디어를 정말 좋아하지만 상대적으로 알려지지 않은 것 같고, 제가 접한 많은 오래된 의견에서는 WF가 일단 들어가면 압도적으로 복잡하다고 언급합니다.

중소 규모 프로젝트에 사용할 수 없을 정도로 과도하게 설계되었다면(또는 나쁜 상충 관계), 그것이 제가 알아야 할 사항입니다.

물론 2006년 후반부터 나왔으니 성숙해진 게 아닐까.만약 그렇다면, 그것은 매우 도움이 될 또 다른 정보입니다!

미리 감사드립니다!

도움이 되었습니까?

해결책

Windows Workflow Foundation은 매우 뛰어난 제품이지만 첫 번째 버전에서는 여전히 많은 기능을 제공합니다. :-(

사용하는 주요 이유는 다음과 같습니다.

  1. 비즈니스 요구 사항을 시각적으로 모델링합니다.
  2. 비즈니스 규칙에서 비즈니스 논리를 분리하고 규칙을 XML 파일로 외부화합니다.
  3. 워크플로를 XML 파일로 외부화하여 애플리케이션에서 비즈니스 흐름을 분리합니다.
  4. 일정 기간 동안 아무 일도 일어나지 않으면 자동으로 반응하는 기능을 갖춘 장기 실행 프로세스를 생성합니다.예를 들어 청구서가 지불되지 않았습니다.
  5. 장기 실행 워크플로의 자동 지속성을 통해 리소스 사용량을 낮추고 프로세스 및/또는 시스템을 다시 시작할 수 있습니다.
  6. 비즈니스 요구 사항에 도움이 되는 작업 흐름을 자동으로 추적합니다.

WF는 라이브러리/프레임워크로 제공되므로 대부분의 경우 WF 런타임을 인스턴스화하는 호스트를 작성해야 합니다.즉, IIS에서 호스팅되는 WCF를 사용하는 것은 실행 가능한 솔루션이며 많은 작업을 절약합니다.그러나 WCF/WF 결합은 완벽하지 않으며 심각한 작업이 필요합니다.여기를 보아라 http://msmvps.com/blogs/theproblemsolver/archive/2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx 상세 사항은.다음 버전에서는 많은 변경/개선이 있을 것으로 예상됩니다.

WF(및 WCF)는 Microsoft에서 나오는 많은 새로운 기능의 핵심입니다.PDC에서 몇 가지 흥미로운 발표를 기대할 수 있습니다.

여러 버전의 워크플로를 실행 중인 상태로 유지하려면 약간의 작업이 필요하지만 이는 대부분 표준 .NET입니다.방금 여기에서 시작하여 주제에 대한 일련의 블로그 게시물을 작성했습니다. http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx

비즈니스 요구 사항을 시각적으로 모델링하는 방법에 대해 설명합니다.이론적으로 이는 의도와 구현을 분리하면 매우 잘 작동합니다.그러나 실제로는 순전히 기술적인 이유로 워크플로에서 몇 가지 추가 활동을 삭제하게 되며 비즈니스 분석가에게 모양과 선의 절반을 무시하라고 지시해야 하기 때문에 이러한 종류의 목적은 무산됩니다.

다른 팁

관련 질문: Windows Workflow Foundation을 언제 사용해야 합니까? 내 대답은 다음과 같습니다.

다음 중 하나가 사실 인 경우에만 WF가 필요할 수 있습니다.

  1. 장기 실행 프로세스가 있습니다.
  2. 자주 변경되는 프로세스가 있습니다.
  3. 프로세스의 시각적 모델이 필요합니다.

자세한 내용은 Paul Andrew의 게시물을 참조하십시오. Windows Workflow Foundation의 용도?

WF를 어떤 종류의 시각적 프로그래밍과 혼동하거나 관련시키지 마십시오.그것은 잘못되었고 건축/디자인 결정으로 이어질 수 있습니다.

따라서 그러한 요구 사항이 있는 경우 WF가 좋은 후보입니다.물론 비교적 복잡하지만 해결하려는 문제도 복잡하다는 점을 언급합니다(때로는 매우 복잡함).IMHO, 예를 들어 이벤트 핸들러가 연결된 객체(객체가 메모리에 없을 때 트리거될 수 있는 이벤트 포함)를 탈수/재수화하는 것은 매우 복잡합니다.

"중소형 프로젝트"가 무엇을 의미하는지 판단할 수는 없지만 일반적으로 프로젝트에 위 목록의 두 가지 요구 사항이 있는 경우 WF를 솔루션으로 고려할 수 있습니다.

우리는 대규모 SharePoint 응용 프로그램에서 WF를 사용해 본 적이 있으며 괜찮다고 말할 수 있습니다.그것은 많은 힘과 유연성을 가지고 있습니다.그리고 Kevin이 언급한 것처럼 일단 워크플로의 기본 개념을 파악하고 나면 이를 통해 원하는 거의 모든 작업을 수행할 수 있습니다.

반면에 버전 관리 부족과 같은 심각한 문제가 있어 향후 애플리케이션에 큰 타격을 줄 수 있습니다.이전 인스턴스를 계속 실행하고 새 인스턴스가 업데이트된 버전을 사용하도록 하려면 xxx-v1, xxx-v2 및 xxx-v3이라는 동일한 워크플로의 최대 3개 병렬 버전을 배포해야 했습니다.진짜 골치 아프다.아, 그리고 거기에는 매우 직관적이지 않은 개념도 있습니다(상관 토큰, 뭐??)

직장에서 Workflows를 사용하는 프로젝트가 있었습니다.(경영진의) 아이디어는 우리 프로그래머가 "엔진" 및 프레임워크와 함께 워크플로 활동을 작성한다는 것이었습니다.그런 다음 프로그래머가 아닌 사람들은 자신의 작업 흐름을 엔진이 자동으로 로드하는 dll로 컴파일하여 나머지 모든 작업을 처리합니다.

경영진은 프로그래머가 아닌 사람도 Workflow를 사용하여 소프트웨어 개발을 돕는다는 아이디어를 믿었고 이는 거의 완전한 시간 낭비였습니다.우리가 이 프로젝트에서 해결하려고 했던 문제는 상대적으로 복잡했으며 소프트웨어가 거의 지속적으로 수정되어야 한다는 것을 처음부터 알고 있었습니다(해당 계산은 다른 회사 및 정부에 따라 달라졌습니다).

최종 결과는 다른 사람이 사용할 수 있을 만큼 일반적인 워크플로 모듈을 만들 수 없다는 것이었습니다.따라서 프로그래머는 워크플로를 사용하여 작업하도록 강요받은 사람들이었고 워크플로가 수행한 모든 작업은 우리를 방해했습니다.

저는 지난 몇 달 동안 Workflow 4.0을 사용해 왔지만 대부분 인상적이었지만 배우기가 매우 어렵다는 것을 알았습니다.

.NET 4.0 RC와 함께 제공되는 최신 버전의 경우 웹이나 책에 문서가 거의 없으며 교육 과정도 없습니다.현재는 존재하지 않는 3.0 버전과 관련된 기사만 찾았습니다.MSDN 문서조차도 간단합니다.

워크플로 디자이너는 직관적이지 않기 때문에 학습이 매우 어렵습니다.저는 StackOverflow에서 한 사람의 답변에 의존해야 했습니다(Maurice에게 감사드립니다!). 그리고 그의 도움이 없었다면 저는 답답했을 것입니다.

요약하자면, 잠재력이 있다고 생각하지만 아직 배우려면 상당히 화가 났을 것입니다. 더 많은 교육, 문서 및 책을 기다리지 않으면 맹목적으로 들어갈 것입니다!

작년에 우리는 WF를 사용하여 작업 응용 프로그램을 완료했습니다. 현재는 매우 큰 은행에서 모기지 프로세스를 위해 사용하는 믿을 수 없을 정도로 거대한 시스템의 백본으로 사용되고 있습니다.PE 프로세스는 고객 신청부터 신용 승인까지 여러 단계로 구성됩니다.

비록 성공했지만 그 과정에는 너무나 많은 문제와 위기가 있었습니다.그리고 소규모 프로젝트에서는 문제를 일으킬 가치가 없습니다.

나는 MS WF를 K2와 같은 완전한 기업용 워크플로 제품이 아니라 낮은 수준의 워크플로 라이브러리로 간주합니다.이를 통해 워크플로 지원 애플리케이션을 구축할 수 있지만 그 자체가 워크플로 애플리케이션은 아닙니다.비록 우리가 이를 중심으로 많은 자체 인프라(pub/sub 프레임워크, 작업 흐름 수명 관리자 등)를 구축해야 했지만 이 역량에 대한 나의 경험은 긍정적이었습니다.시중의 많은 문서는 상당히 단순하며 MS WF를 기반으로 하는 엔터프라이즈 워크플로 응용 프로그램 구축을 다루지 않습니다.

배우기가 어렵습니다.매우 유연합니다.프로그래머만을 위한 최종 사용자용 시각적 도구와 혼동하지 마십시오.종속성 속성 접근 방식이 마음에 드는지 잘 모르겠습니다.

그것은 정말로 당신이 그것으로 무엇을 하고 싶은지에 달려 있습니다.저는 이 제품을 조금만 사용해 봤지만 MetaStorm(기술적으로 BPM인 것은 알지만 여전히 워크플로우 구성요소가 있음), Process Choriographer 및 IBM MQ 워크플로우와 같은 보다 성숙한 제품과 비교할 수 없습니다.아직 충분히 성숙하지 못했을 뿐입니다.반면에 다른 사람들이 하지 않는 곳에서는 무료이며 아마도 작업을 완료할 수 있습니다.수백만 달러 규모의 작업을 수행할 것인지는 모르겠지만 규모가 작은 경우에는 한 번 더 시도해 볼 것입니다.당신이 직면하게 될 실제 장애물은 필요한 사고 과정의 변화입니다.이전에 상태 시스템을 사용해 본 개발자가 없다면 이는 큰 장애물이 될 수 있습니다.

브라이언, 귀하의 의견에 답변할 수는 없지만 버전 관리란 이미 실행 중인 인스턴스를 중단하지 않고 워크플로의 기본 코드를 변경하고 기존 워크플로에 업데이트를 정상적으로 적용하는 것을 의미합니다.'스톡' WF에 대해서는 잘 모르겠지만 적어도 SharePoint 환경에는 워크플로 버전에 대한 개념이 없으므로 새 버전은 유지 관리가 악몽이 되는 완전히 다른 워크플로로 배포되어야 합니다.이는 '재수화'와는 아무런 관련이 없습니다. 복원은 일부 이벤트나 상태 변경 후 '휴면' 워크플로를 다시 활동으로 가져오는 프로세스입니다.이는 워크플로 런타임에 의해 투명하게 처리됩니다.

WF는 SharePoint(WSS 3.0)에 통합되어 있지 않으며 다양한 SharePoint 웹 사이트에 대해 꽤 많은 워크플로를 만들었으므로 SharePoint에서 WF를 사용한 경험을 말씀드릴 수 있습니다.다른 워크플로 프레임워크와 비교하면 WF 점수가 좋습니다.안정적이고(알 수 없는 오류가 발생하지 않았습니다) 워크플로는 설계하기가 매우 쉽고(Visual Studio의 워크플로 디자이너 덕분에) 순차 워크플로는 물론 상태 머신 워크플로도 사용할 수 있습니다.

물론 완벽하지는 않으며 개발자가 개념(예:활동 모델)하지만 "작은 작업"에도 확실히 사용할 수 있습니다.

WFF를 시도해본 적은 없지만 읽은 기억이 납니다. Leon Babrick의 WFF 관련 기사 그는 기본적으로 소프트웨어 개발 도구의 전체 장르가 말도 안된다고 말합니다.어느 쪽이든 결정하는 데 도움이 될 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top