BizTalk Server 2006 또는 WF? 프로젝트에 적합한 워크플로 도구 선택

2008-03-19

켄트 브라운

twentysix New York (www.26ny.com)

2007년 11월

수정일: 2008년 2월

적용 대상:

Microsoft BizTalk Server 2006

Windows Workflow Foundation

요약: 이 문서에서는 다양한 애플리케이션 및 엔터프라이즈 통합 워크플로 시나리오에서 Microsoft BizTalk Server 2006과 Windows Workflow Foundation 중에서 선택하는 지침을 제공합니다. (인쇄된 페이지 16개)

워크플로는 일상적인 비즈니스 프로세스에 만연하므로 워크플로 솔루션 빌드를 직접 지원하는 프로그래밍 도구를 찾는 것이 일반적입니다. Microsoft BizTalk Server 2006 및 WF(Windows Workflow Foundation)는 워크플로 솔루션을 프로그래밍하기 위한 Microsoft의 두 가지 주요 도구입니다. 그러나 두 설계자 간의 명백한 겹침으로 인해 많은 설계자와 개발자는 목적에 적합한 워크플로 기술을 결정하는 데 어려움을 겪습니다.

BizTalk Server 2006은 여전히 엔터프라이즈 통합을 위한 프리미엄 서버 제품인 반면, WF가 앞으로 선호하는 워크플로 기술로 명확하게 식별되었다는 점을 감안할 때 특히 그렇습니다. BizTalk Server 오케스트레이션이 WF를 완전히 지원할 때까지 설계자와 개발자는 투자할 기술을 신중하게 선택해야 합니다.

워크플로를 구현하는 데 적합한 기술을 선택하는 경우의 과제 중 하나는 워크플로가 많은 것을 의미할 수 있다는 점입니다.

사용자가 작업을 완료하기 위해 상호 작용하는 UI 화면의 흐름입니다.
애플리케이션 또는 서비스 내의 비즈니스 논리 흐름입니다.
여러 사람의 상호 작용을 통해 비즈니스 프로세스를 완료합니다.
시스템 간에 여러 메시지 교환을 조정하여 비즈니스 트랜잭션을 처리합니다.
ETL(데이터를 데이터베이스로 추출, 변환 및 로드하기 위한 단계 조정)

워크플로 시나리오의 범위는 넓지만 휴먼 워크플로, 애플리케이션 워크플로, 엔터프라이즈 통합 워크플로및 데이터 통합 워크플로네 가지 범주로 그룹화하면 도움이 됩니다.

네 가지 주요 워크플로 범주 중 애플리케이션 워크플로 및 엔터프라이즈 통합 워크플로는 사람들이 기술을 선택하는 것이 가장 어려운 두 영역입니다. 휴먼 워크플로 및 데이터 통합 워크플로 시나리오는 도구 선택 관점에서 매우 간단합니다. 휴먼 워크플로에는 사용자 인터페이스가 필요하며 종종 문서 중심이므로 Microsoft Office SharePoint Server 2007이 휴먼 워크플로 솔루션을 빌드하는 데 권장되는 플랫폼입니다. Microsoft SSIS(SQL Server Integration Services)는 데이터 통합 시나리오에 권장되는 도구입니다.

이 문서에서는 애플리케이션 워크플로 및 엔터프라이즈 통합 워크플로 시나리오에서 BizTalk Server 2006과 WF 중에서 선택하는 지침을 제공합니다.

BizTalk Server 오케스트레이션 엔진

BizTalk Server 오케스트레이션 엔진은 항상 BizTalk Server의 강력한 기능 중 하나입니다. 도입되었을 때 워크플로 중심 프로그래밍을 수행하기 위해 Microsoft에서 사용할 수 있는 최상의 도구였습니다. BizTalk Server 오케스트레이션은 복잡한 다중 단계 메시지 흐름을 제어하여 특정 비즈니스 트랜잭션을 완료하는 구성 요소를 개발하기 위한 시각적 프로그래밍 환경을 제공합니다.

BizTalk Server 오케스트레이션 코드 아티팩트는 비즈니스 분석가가 비즈니스 프로세스를 문서화하기 위해 생성할 수 있는 순서도 또는 UML(통합 모델링 언어) 작업 다이어그램과 매우 유사합니다. 그런 다음, 이러한 아티팩트를 오케스트레이션 엔진 런타임에서 컴파일하고 실행할 수 있으며, 이는 중요 업무용 비즈니스 트랜잭션을 자동화하는 시스템을 구축하는 데 중요한 장기 실행 트랜잭션 및 보상, 내구성, 내결함성 및 재해 복구와 같은 서비스를 제공합니다.

미래를 위한 워크플로 파운데이션

워크플로 시나리오에는 고유한 범주가 있지만, 프로그래밍 관점에서 시나리오 간에 공통적인 공통 프레임워크를 설정하는 것이 좋습니다. BizTalk Server의 오케스트레이션 엔진은 강력하지만 BizTalk Server 외부에서 사용하도록 설계되지 않았습니다. 따라서 다른 워크플로 범주에 대해 BizTalk Server 오케스트레이션을 효과적으로 용도를 다시 지정하는 것은 불가능합니다.

Microsoft .NET Framework 3.0에서 릴리스된 WF는 앞으로 Windows 플랫폼의 모든 워크플로 관련 시나리오에서 사용할 수 있을 만큼 일반적이고 확장 가능하도록 설계된 시각적인 워크플로 중심 프로그래밍 모델을 .NET Framework에 도입합니다. WF를 생성한 팀은 BizTalk Server 오케스트레이션 엔진의 최상의 개념을 사용하고, 워크플로 시나리오의 광범위한 영역에 대한 요구 사항을 고려하고, 모두 지원할 수 있을 만큼 유연한 프레임워크를 설계할 수 있었습니다.

WF의 유연성에 대한 증거로 Microsoft Office SharePoint Server 2007은 이를 사용하여 휴먼 워크플로 솔루션을 구현합니다. 타사 BPM 공급업체는 자체 소유 워크플로 엔진을 빌드하는 대신 WF를 기반으로 솔루션을 빌드하기 위한 것입니다. 여러 공급업체가 이미 그렇게 했습니다. 개별 개발자는 WF를 사용하여 .NET Framework 애플리케이션에서 사용자 지정 애플리케이션 워크플로를 구현할 수도 있습니다. 또한 향후 버전의 BizTalk Server에서 엔터프라이즈 통합 워크플로 솔루션을 구현하기 위한 오케스트레이션 엔진을 WF에 구현할 계획입니다.

그림 1. 올바른 워크플로 도구 사용: BizTalk Server 2006 및 WF

올바른 워크플로 도구 선택 프로세스

프로젝트에 적합한 워크플로 도구를 결정하는 데 도움이 되는 지침을 제공하는 방법은 프로젝트에 가장 적합한 시나리오 또는 시나리오 조합을 결정할 수 있도록 가장 일반적인 워크플로 시나리오를 설명하는 것입니다. 그런 다음, 어떤 도구(BizTalk Server 2006 또는 WF)가 가장 적합한지와 그 이유에 대한 각 시나리오에 대한 구체적인 지침을 제공합니다. 또한 조직의 애플리케이션 플랫폼 및 개발 기능의 완성도를 평가하는 모델인 APIO(애플리케이션 플랫폼 인프라 최적화) 모델을 사용하여 두 도구 중 하나를 효과적으로 사용할 수 있는 시나리오에서 조직별 지침을 제공합니다. 마지막으로, BizTalk Server 2006 및 WF에 대한 로드맵을 살펴보고, 현재 빌드 중인 애플리케이션을 미래 지향적으로 결정하기 위한 최선의 결정을 내릴 수 있도록 합니다.

일반적인 워크플로 시나리오

범위를 워크플로의 애플리케이션 및 엔터프라이즈 통합 범주로 제한한 후에도 고려해야 할 광범위한 워크플로 시나리오가 있습니다. 그림 2에서 볼 수 있듯이 스펙트럼의 한쪽에는 WF가 올바른 선택이라는 시나리오가 있습니다. 예를 들어 ISV(독립 소프트웨어 공급업체) 제품 내의 워크플로 기능으로, BizTalk Server 2006의 라이선스 비용과 배포 복잡성이 매우 복잡합니다. 이 시나리오에서 ISV는 상용 소프트웨어를 만드는 사업을 하고 있으며, WF 로열티 프리를 호스트하는 데 필요한 추가 프로그래밍 노력은 합리적인 투자입니다.

그림 2. 통합 및 워크플로 연속체

반면에 BizTalk Server 2006이 적합한 회사 IT 부서 내에 구축된 엔터프라이즈 통합 솔루션이 있습니다. 이 시나리오에서는 솔루션을 확장 가능하고 안정적이며 관리할 수 있도록 "배관"을 빌드하는 데 투자하는 대신 비즈니스 가치를 생성하는 데 집중하려고 합니다. 따라서 BizTalk Server 2006의 라이선스 비용은 제공하는 것 때문에 가치가 있습니다.

대부분의 프로젝트는 스펙트럼의 이 두 끝 사이에 있습니다. 다음은 요구 사항에 따라 워크플로 솔루션이 결정되는 몇 가지 일반적인 시나리오입니다.

UI 페이지 컨트롤러- 복잡한 애플리케이션의 일반적인 요구 사항은 구현되는 특정 사용 사례의 비즈니스 규칙에 따라 UI 화면 탐색을 적용하는 것입니다. 가장 간단한 예는 사용자가 지정된 화면 집합을 안내하여 작업을 수행하는 마법사입니다. 종종 사용자의 작업 및 데이터 상태를 기반으로 하는 화면 탐색 가능성의 더 복잡한 그래프입니다.
MVC(Model-view-controller) 패턴은 이 탐색 논리를 양식 자체에서 끌어와 다양한 사용 사례에서 더 간단하고 재사용할 수 있도록 하는 클래식 기술입니다. MVC 패턴의 컨트롤러는 실제로 워크플로 또는 상태 컴퓨터입니다. 따라서 이러한 종류의 애플리케이션을 구현하는 워크플로 도구를 찾는 것은 당연합니다.
장기 실행 비즈니스 논리- 비즈니스 트랜잭션을 완료하기 위해 많은 단계가 필요한 경우 사용자는 프로세스 중간에 중지하거나 계속하기 전에 다른 사용자 또는 시스템의 작업을 기다려야 할 수 있습니다. 프로세스를 일시적으로 일시 중지(또는 "최대 절전 모드")한 다음 외부 이벤트에 따라 다시 시작하는 기능은 워크플로의 개념의 핵심입니다. 워크플로 엔진이 없으면 개발자는 불완전한 프로세스의 상태를 저장하고 프로세스가 계속되면 해당 상태를 회수하기 위한 메커니즘을 수동으로 디자인하고 코딩해야 합니다. 잘 설계된 워크플로 엔진에서 이 기능은 개발자를 위한 추가 작업 없이 기본적으로 지원됩니다.
동적으로 업데이트 가능한 프로세스 흐름- 처음에는 비즈니스 프로세스를 잘 정의된 순차적 단계로 명문화할 수 있는 것처럼 보이지만, 인간은 실제 상황을 고려하여 흐름 중간 스트림을 수정해야 하는 경우가 많습니다. 비용 승인 프로세스에서 비용 보고서를 제출한 직원의 관리자가 기본 승인자일 수 있습니다. 그러나 관리자는 작업을 비서에게 위임하거나(예: 관리자가 골프를 치기 위해 나가기 때문에) 승인을 상사에게 에스컬레이션할 수 있습니다(예: 관리자가 특정 비용에 대한 정책을 잘 모르기 때문). 사용자가 흐름을 업데이트하도록 허용하는 것은 흐름의 가능한 모든 순열을 미리 예상하는 것보다 더 간단한 경우가 많습니다.
비즈니스 논리규칙 추상화 - 이 시나리오에서는 비즈니스 규칙을 다른 비즈니스 논리와 분리하는 것이 목표입니다. 좋은 예는 양식 유효성 검사 규칙입니다. 모기지 애플리케이션 프로그램에서 대출 신청 양식에는 필드 유효성 검사 규칙 집합이 하나 있을 수 있습니다. 사용자가 제출 단추를 눌러 대출 신청서를 제출할 수 있습니다. 대출 담당자가 대출을 검토하고 승인하는 데 동일한 양식을 사용하는 경우 프로세스의 다른 단계에 있기 때문에 추가 유효성 검사 규칙이 필요합니다.
양식과 별도로 유효성 검사 규칙을 구현하면 다양한 시나리오에서 양식을 더 쉽게 재사용하고 해당 시나리오에 대한 적절한 규칙 집합을 평가하여 적절한 유효성 검사 규칙을 적용할 수 있습니다.
웹 서비스 집계- 애플리케이션은 종종 여러 웹 서비스의 데이터를 집계해야 합니다. 대부분의 경우 집계 논리 자체는 애플리케이션에서 추출될 수 있고 추출되어야 하며, 다른 애플리케이션에서 다시 사용할 수 있는 서비스로 자체적으로 노출되어야 합니다. 이러한 서비스는 종종 복합 웹 서비스호출되며 성숙한 서비스 지향 아키텍처의 중요한 요소입니다. 웹 서비스 집계 시나리오는 일반적으로 동기 및 짧은 실행입니다.
장기 실행 비즈니스 프로세스- 이 문서에서는 여러 애플리케이션을 통합하는 서버 기반 프로세스를 지정하는 반면, 비즈니스 논리 단일 애플리케이션 내의 논리에 사용됩니다. 다중 스레딩, 비동기 동작, 프로세스 상태 지속성, 프로세스 인스턴스에 대한 메시지 상관 관계, 확장성, 안정성, 트랜잭션 무결성 등에 대한 이러한 서버 기반 장기 실행 비즈니스 프로세스에 대한 요구 사항은 애플리케이션 내의 비즈니스 논리보다 훨씬 높습니다.
B2B(Business to Business) 프로세스- B2B 프로세스 시나리오는 기본적으로 장기 실행 비즈니스 프로세스 시나리오와 동일합니다. 단, 전자는 내부 애플리케이션 외에 조직 간에 있습니다. 따라서 보안 요구 사항이 가장 중요합니다. 또한 비즈니스 파트너가 지시할 수 있으므로 특정 데이터 형식 및 전송 프로토콜을 훨씬 더 적게 제어할 수 있습니다. 따라서 광범위한 형식 및 프로토콜을 지원하고 많은 파트너를 위한 특정 교환 구성을 지원하는 기능이 필요합니다.
비즈니스 프로세스에서 규칙 추상화- 비즈니스 논리 시나리오에서 규칙 추상화와 유사하게 이 시나리오는 장기 실행 비즈니스 프로세스 시나리오 및 B2B 프로세스 시나리오의 주 코드에서 비즈니스 규칙을 분리하려는 경우에 적용됩니다. 이 시나리오에는 더 높은 수준의 성능과 확장성이 필요합니다. 또한 프로그래머가 아닌 사용자가 규칙을 보고 편집할 수 있도록 하는 도구가 필요할 수 있습니다.
엔터프라이즈 규칙 리포지토리— 이 시나리오에서는 엔터프라이즈의 모든 애플리케이션에서 호출할 수 있는 중앙 공유 규칙 리포지토리를 빌드하는 것이 목표입니다. 이렇게 하면 조직의 모든 애플리케이션에서 중요한 비즈니스 규칙을 적용하기 위한 일관성을 제공합니다. 비즈니스 프로세스 시나리오에서 규칙 추상화와 마찬가지로 이 시나리오에는 비프로그래머가 규칙을 보고 편집할 수 있도록 하는 높은 확장성 및 도구가 필요합니다. 또한 이 시나리오에서는 규칙 리포지토리가 워크플로 엔진과 별개인 자체 호스팅 메커니즘 및 다양한 애플리케이션에서 규칙을 실행하기 위한 구성 요소 또는 API를 사용하여 엔터프라이즈에서 자체 엔터티로 존재할 수 있어야 합니다.
ESB(Enterprise Service Bus)/Message Broker- 많은 조직에서 모든 서비스에 대해 표준화된 통신 인프라를 원합니다. 이 인프라에 대한 가장 일반적인 두 가지 토폴로지로는 ESB와 Message Broker가 있습니다. 게시/구독 메시징 및 토픽 기반 라우팅은 일반적으로 이 인프라의 예상 기능입니다.

애플리케이션 플랫폼 인프라 최적화 모델

일부 워크플로 시나리오에서 BizTalk Server 2006 및 WF는 모두 기술 요구 사항을 만족스럽게 충족합니다. 이러한 시나리오의 경우 올바른 워크플로 기술을 선택하려면 솔루션을 특정 조직의 요구에 일치시켜야 합니다. 특정 조직에 적용되는 권장 사항을 만들기 위해 그림 3과 같이 APIO(애플리케이션 플랫폼 인프라 최적화) 모델을 사용합니다.

그림 3. APIO(애플리케이션 플랫폼 인프라 최적화) 모델

APIO 모델은 애플리케이션 인프라, 아키텍처 및 개발 관행과 관련하여 조직의 완성도를 프로파일링하는 기술입니다. 이 모델의 목표는 조직의 민첩성을 최적화하기 위한 로드맵을 제공하여 비즈니스 요구 사항을 충족하는 IT 솔루션을 제공하는 것입니다.

APIO 모델은 조직의 완성도에 대한 다음 네 가지 프로필을 사용합니다.

기본— 조직은 소프트웨어를 비용으로 취급합니다. 통합 또는 재사용이 거의 없는 주로 사일로 애플리케이션이 있습니다. 이러한 애플리케이션은 다양한 플랫폼에 있을 수 있습니다. 인프라 또는 개발 기술에 대한 일관된 표준이 없습니다. 일관된 아키텍처 비전이 없습니다.
표준화된- 조직은 여전히 소프트웨어를 비용으로 처리하지만 효율성을 개선하기 위한 조치를 취했습니다. 아키텍처 비전이 있으며 재사용 기회를 고려하려고 합니다. 일부 애플리케이션을 통합하기 시작했지만 대부분 지점 및 지점 통합입니다.
고급— 조직은 소프트웨어를 비즈니스 지원자로 취급합니다. 그들은 헌신적 인 건축가와 명확한 건축 비전을 가지고 있습니다. 많은 서비스가 있으며 높은 수준의 재사용을 달성합니다. 모든 핵심 비즈니스 프로세스는 자동화되고 모니터링됩니다. 중앙 집중식 패키지 통합 플랫폼을 사용합니다.
동적— 조직은 소프트웨어를 전략적 자산으로 취급합니다. 그들은 비전과 구현에서 매우 성숙한 SOA를 가지고 있습니다. 동적으로 서비스를 버전 관리 및 다시 배포하기 위한 명확한 프로세스가 있습니다. 비즈니스 요구 사항 변경에 빠르게 적응할 수 있으며 새 비즈니스 파트너와 빠르게 통합할 수 있습니다.

그것은 단지 당신이 어디에 있는지가 아니라 어디로 가고 있는지입니다.

APIO 모델에서 다소 암시적인 것은 모든 조직이 동적 프로필로 이동하려고 한다는 개념입니다. 실제로, 그것은 비즈니스의 본질과 기술에 관한 관리의 철학에 따라 달라집니다. 일부 기업은 기본 또는 표준화된 프로필을 유지하는 데 완전히 만족할 수 있습니다.

단기 및 장기 목표뿐만 아니라 현재 프로필을 고려해야 하며, 단기 목표가 가장 중요합니다. 결국 동적 프로필에 속하려는 기본 프로필의 조직은 처음에 표준화된 프로필에 들어가는 데 집중하도록 현명하게 선택할 수 있습니다. 따라서 기술 결정은 대부분 표준화된 프로필과 일치해야 합니다.

일반적으로 BizTalk Server 2006은 고급 또는 동적 프로필에 있는 조직에 더 적합하거나 단기적인 목표를 가지고 있습니다. 이 프로필에 상대적으로 만족하는 기본 프로필의 조직은 BizTalk Server 2006을 채택하려는 전략적 동기나 이를 효과적으로 활용할 수 있는 기능이 없는 것일 수 있습니다. 그래서, 그들은 가능성이 투자를하고 싶지 않을 것입니다. 그러나 기본 프로필의 조직에서 고급 프로필로 적극적으로 이동하기로 결정한 경우 BizTalk Server 2006을 채택하는 것이 해당 방향으로 전략적 단계가 될 수 있습니다.

APIO 모델을 소개하는 요점은 조직의 현재 및 대상 APIO 프로필을 잘 파악하면 기술 시나리오가 어느 기술에서든 잘 지원될 수 있는 WF와 BizTalk Server 2006을 결정하는 데 도움이 될 것이라는 점입니다. 서로 다른 두 조직이 서로 다른 선택을 할 수 있습니다. 각 조직은 조직 프로필에 적합한 선택을 합니다.

호스트의 모든 항목

BizTalk Server 2006과 WF 중에서 선택할 때 고려해야 할 가장 중요한 측면 중 하나는 워크플로에 대한 호스팅 요구 사항입니다. BizTalk Server 2006과 달리 WF는 호스팅 "기본 제공"을 제공하지 않습니다. Windows 프로세스를 설정하고 워크플로가 실행되는 워크플로 런타임 엔진을 시작하는 호스트를 구현해야 합니다.

워크플로 시나리오의 전체 스펙트럼을 현실적으로 지원할 수 있는 프레임워크를 빌드하기 위해 WF는 BizTalk Server 2006과 같은 환경에서 제공하는 핵심 동작을 추상화하여 다양한 호스트가 이러한 서비스에 대해 원하는 특정 동작을 제공할 수 있도록 합니다.

WF 워크플로 호스트에서 제공하는 핵심 서비스는 다음과 같습니다.

예약 서비스- 런타임 엔진에서 워크플로 인스턴스를 실행하는 데 사용되는 스레드를 만들고 관리합니다.
Work Batch 서비스커밋 - 런타임 엔진에서 데이터베이스 작업에 사용하는 트랜잭션을 관리합니다.
지속성 서비스- 워크플로 인스턴스가 런타임 엔진에서 수행하도록 지시될 때 워크플로 인스턴스의 지속성을 처리합니다. 이 서비스는 선택 사항입니다. 이 인스턴스가 제공되지 않으면 워크플로 인스턴스는 유지되지 않으며 전체 수명 동안 메모리 내를 실행해야 합니다.
추적 서비스- 워크플로 내에서 추적 이벤트를 기록하는 기능을 제공합니다. 이 서비스는 선택 사항입니다.

워크플로 호스트를 빌드하는 데 필요한 사항

워크플로 시나리오 및 워크플로에 제공해야 하는 서비스에 따라 WF 호스트를 빌드하는 것은 사소하거나 금지될 수 있습니다. 워크플로가 애플리케이션의 컨텍스트 내에 있는 시나리오의 경우 WF 호스팅은 매우 간단합니다. 애플리케이션 자체는 프로세스 호스트 역할을 하며 최소한의 노력으로 구성할 수 있는 핵심 서비스의 표준 구현이 있습니다.

그러나 확장성이 뛰어난 서버 기반 시나리오에 들어가면 호스트의 필요한 정교함이 크게 뛰어올랐습니다. 표 1에는 필요할 수 있는 호스트 서비스의 세탁 목록이 나와 있으며, 대부분은 BizTalk Server 2006에서 제공됩니다.

표 1. 호스트 서비스

스케일 아웃 구성
부하 분산
장애 조치(failover)
제한
스레드 관리
메모리 관리
서비스 격리
예외 구성
실패한 메시지 관리
메시지 추적

보관 및 제거
ID 및 가장
다중 환경 배포 모델
상태 모니터링
사용률/성능 추적
복합 프로세스 상태 관리
스크립팅
재해 복구
규정 준수
구성 관리

어쨌든 어떤 사업을하고 있습니까?

마감 기한이 촉박한 특정 애플리케이션을 빌드해야 하는 경우 필요한 비즈니스 논리를 구현하는 데 집중해야 할 때 복잡한 호스트를 빌드해야 하는 팀이 방해를 받지 않도록 할 수 있습니다. 이 경우 BizTalk Server 2006은 강력한 워크플로 호스트를 빌드하는 대신 구매할 가치가 있습니다. 대기업의 중앙 아키텍처 팀에 속한 경우 조직 전체에서 사용할 수 있는 호스트를 빌드하는 데 투자하도록 선택할 수 있습니다. 그럼에도 불구하고, 이 노력은 가볍게 받아들여서는 안됩니다.

Workflow-Technology 권장 사항

애플리케이션 내의 시나리오: WF

UI 페이지 컨트롤러, 장기 실행 비즈니스 논리, 동적으로 업데이트 가능한 프로세스 흐름, 웹 서비스 컴퍼지션 및 비즈니스 논리의 규칙 추상화 등 애플리케이션 내에 포함된 모든 시나리오에서 WF는 올바른 워크플로 기술 선택입니다.

대부분의 애플리케이션 중심 시나리오에서 사용 패턴에는 BizTalk Server 2006의 강도가 아닌 애플리케이션과 워크플로 간의 동기적이고 짧은 대기 시간 상호 작용이 필요합니다. BizTalk Server 2006은 성능상의 이유로 이러한 시나리오에 적합하지 않습니다. BizTalk Server 오케스트레이션은 전용 BizTalk 서버에서 실행되며 클라이언트 애플리케이션에서 호출하려면 네트워크를 통해 왕복해야 합니다. 또한 내구성을 위해 MessageBox 데이터베이스에 모든 메시지를 유지하도록 BizTalk Server 2006을 디자인하면 추가 대기 시간이 발생하며, 워크플로를 동기적으로 호출해야 하는 경우 대화형 UI의 컨텍스트에서 허용되지 않을 수 있습니다.

WF는 이러한 시나리오에 더 적합합니다. 워크플로 요구 사항을 충족하며 BizTalk Server 2006보다 더 간단하고 저렴합니다. 이러한 시나리오에서는 BizTalk Server 2006의 메시징 기능(예: 매핑 및 어댑터)이 필요하지 않습니다. 호스팅 서비스에 대한 요구 사항은 적기 때문에 애플리케이션 내에서 WF 런타임을 호스트하는 데 엄청난 양의 작업이 필요하지 않습니다.

대부분의 Business-Process 시나리오: BizTalk Server 2006

서버 기반 비즈니스 프로세스를 포함하는 대부분의 시나리오에서 BizTalk Server 2006이 적합한 선택입니다. 여기에는 B2B 프로세스, 비즈니스 프로세스의 규칙 추상화, 엔터프라이즈 규칙 리포지토리 및 ESB(Enterprise Service Bus)/Message Broker가 포함됩니다.

이러한 시나리오에는 높은 확장성이 필요합니다. 또한 실행 중인 프로세스를 보고 중지하고 다시 시작하는 기능이 필요합니다. 마지막으로, 여러 서버로 확장하기 위한 지원이 필요합니다. 이러한 시나리오에서는 BizTalk Server 2006의 고급 호스팅 기능이 필요하며 투자할 만한 가치가 있습니다.

기초의	표준화	고급	동적인
WF → BizTalk Server 2006	BizTalk Server 2006	BizTalk Server 2006	BizTalk Server 2006

그림 4. 장기 실행 비즈니스 프로세스 시나리오

BizTalk Server 2006은 일반적으로 장기 실행 비즈니스 프로세스 시나리오에 가장 적합한 플랫폼이 될 것입니다. 이러한 프로세스는 비동기, 장기 실행 및 상태 저장인 경향이 있습니다. 이러한 프로세스는 종종 조직에 중요합니다. 따라서 고가용성, 가시성, 보안 및 관리 효율성이 필요합니다. BizTalk Server 2006의 그룹 또는 "팜" 토폴로지를 사용하면 서버 배열을 관리하여 확장성과 중복성을 제공할 수 있습니다.

프로세스 상태를 저장하기 위한 BizTalk Server 2006의 지속성 메커니즘에는 지속형 상태의 개인 정보를 보호하기 위해 강력한 보안이 기본 제공되어 있으며 이는 규제상의 이유로 중요할 수 있습니다. BizTalk Server 2006의 BAM(비즈니스 활동 모니터링)은 실행 중인 프로세스에 대한 적절한 비즈니스 수준의 가시성을 안전한 방식으로 제공합니다. 마지막으로 이러한 시나리오에서는 종종 레거시 시스템을 포함하여 다른 유형의 메시지 형식 및 전송 프로토콜에 대한 지원이 필요합니다.

이러한 이유로 BizTalk Server 2006은 일반적으로 표준화, 고급 및 동적 프로필을 대상으로 하는 조직에 가장 적합합니다. 이러한 조직은 일반적으로 장기 실행 비즈니스 프로세스 시나리오가 비즈니스에 매우 중요하고 기업 내에서 매우 일반적이라고 간주합니다. 따라서 BizTalk Server 2006을 구매하여 표준화된 플랫폼을 설정합니다.

그러나 WF는 기본 APIO 프로필에 있는 조직에 더 나은 선택이 될 수 있습니다. 이러한 조직은 일반적으로 표준화된 애플리케이션 플랫폼 구축에 투자하지 않습니다. 대신 비용을 최소화하기 위해 노력하고 있으며 BizTalk Server 2006의 라이선스 및 하드웨어 비용은 엄청나게 많을 수 있습니다. 이 지침의 예외는 광범위한 메시지 형식 및 전송 프로토콜에 대한 높은 확장성, 모니터링 및 지원에 대한 요구 사항이 있는 경우입니다. 이 경우 조직은 애플리케이션 플랫폼에 투자하기를 꺼리지만 호스팅 및 메시징 기능을 처음부터 빌드하는 비용이 BizTalk Server 2006의 비용을 초과할 가능성이 높습니다.

기초의	표준화	고급	동적인
WF	WF → BizTalk Server 2006	BizTalk Server 2006	BizTalk Server 2006

그림 5. 웹 서비스 집계 시나리오

BizTalk Server 오케스트레이션과 WF 워크플로는 모두 워크플로에서 외부 사용 웹 서비스를 지원하고 워크플로를 웹 서비스로 노출할 수 있습니다. 따라서 장기 실행 비즈니스 프로세스 솔루션과 마찬가지로 웹 서비스 집계 솔루션을 빌드하는 경우 선택은 조직 프로필 및 호스팅 요구 사항에 따라 결정됩니다.

집계 웹 서비스가 다른 웹 서비스를 집계하기 위한 것일 경우 BizTalk Server 2006에서 다른 유형의 메시지 형식 및 전송 프로토콜을 지원하는 기능은 거의 가치가 없습니다. 그러나 서비스에서 웹 서비스로 노출되지 않은 레거시 환경에서 데이터를 집계해야 하는 경우 BizTalk Server 2006은 값을 추가합니다.

사용 패턴은 빠르고 동기적인 요청/응답 호출이므로 BizTalk Server 2006에서 제공하는 메시지 내구성은 일반적으로 중요하지 않습니다. 실제로 MessageBox에 대한 지속성으로 인해 발생하는 대기 시간은 실제로 책임입니다. BizTalk Server 2006에서 이 시나리오에 제공하는 주요 값은 여러 서버에서 배포를 관리하고 실행 중인 인스턴스를 모니터링하는 기능입니다. BizTalk Server 2006의 BAM 기능은 SLA(서비스 수준 계약)가 충족되는지 모니터링하는 데도 유용할 수 있습니다.

이러한 이유로 WF는 특히 기본 및 표준화된 프로필의 조직에서 웹 서비스 집계를 구현하는 데 매우 적합합니다. BizTalk Server 2006이 유리할 수 있는 예는 여러 클라이언트 조직에 대해 많은 수의 엔드포인트를 관리해야 하는 예제입니다. BizTalk Server 2006의 수신 포트 및 수신 위치 구성은 특히 이를 처리합니다. 이 경우 인증서도 중요할 수 있으며 인증서를 구성 및 관리하고 암호화/암호 해독에 적용하기 위해 BizTalk Server 2006을 지원하는 것이 유용할 수 있습니다.

Future-Proofing

소프트웨어 라이선스 비용, 워크플로 기술 학습 및 특정 워크플로 구성 요소 빌드에 대한 투자가 향후 가장 가능한 가치를 제공할 수 있도록 보장하려고 합니다. 특정 워크플로 시나리오 및 조직에 적합한 워크플로를 선택하는 것 외에도 BizTalk Server 2006 및 WF에 대한 제품 로드맵도 고려해야 합니다. 이에 대한 간단한 대답은 없습니다. 다음 주석 중 하나를 선택 하기 위한 강력한 인수를 하지 않습니다.; 대신 의사 결정에 도움이 되는 데이터 포인트입니다.

BizTalk Server 2006 R2가 추가하는 내용

BizTalk Server 2006 R2는 선택한 워크플로 플랫폼에 영향을 줄 수 있는 두 가지 기능인 WCF 어댑터와 WCF 및 WF용 BAM 인터셉터를 추가합니다.

WCF 어댑터

팀이 SOA를 빌드할 때 서비스를 구현하기 위한 표준 기술로 WCF(Windows Communication Foundation)를 채택한 경우 BizTalk Server 2006에 WCF 지원이 없다는 사실은 복합 웹 서비스를 빌드하고 호스팅하기 위한 플랫폼으로 자격을 박탈했을 수 있습니다. BizTalk Server 2006이 시나리오 및 APIO 프로필과 매우 일치하는 경우에도 WF로 푸시되었을 수 있습니다.

다행히 BizTalk Server 2006 R2에서 훌륭한 WCF 통합이 도입되어 더 이상 문제가 되지 않습니다. BizTalk Server 2006은 이제 WCF와 강력한 통합을 보유하고 있으며, 보다 세분화된 서비스에서 복합 서비스를 구축하고 이러한 복합 서비스를 WCF 서비스로 노출하기 위한 훌륭한 플랫폼입니다.

WF용 BAM 인터셉터

두 번째 관련 BizTalk Server 2006 R2 기능은 WF용 BAM 인터셉터의 도입입니다. 비즈니스 활동 모니터링이 솔루션의 중요한 기능인 경우 WF가 시나리오에 더 적합한 경우 BAM을 활용하기 위해 BizTalk Server 2006을 사용하도록 푸시되었을 수 있습니다. WF용 BAM 인터셉터를 사용하면 프로젝트에 적합한 워크플로 기술인 경우 WF를 선택하고 여전히 BAM을 엔터프라이즈 비즈니스 활동 모니터링 솔루션으로 사용할 수 있습니다.

BAM은 BizTalk Server 오케스트레이션 및 메시지 흐름에서 이벤트 및 데이터를 캡처하고 비즈니스 사용자에게 비즈니스 프로세스에 대한 엔드투엔드 가시성을 제공하기 위해 포털에서 해당 데이터를 제공하는 프레임워크를 제공하는 BizTalk Server 2006의 기능입니다. BIzTalk Server 2006 애플리케이션에서 BAM이 작동하는 방식의 강력한 측면은 BizTalk Server 2006 코드 아티팩트를 수정할 필요 없이 BizTalk Server 2006 애플리케이션이 배포된 후 BAM 모니터링을 구성(또는 "계측")할 수 있다는 것입니다.

BAM은 엔터프라이즈 차원의 비즈니스 활동 모니터링 솔루션으로 설계되었습니다. 따라서 비 BizTalk Server 2006 애플리케이션에서 이벤트 및 데이터를 BAM에 공급할 수 있습니다. 그러나 이렇게 하려면 API를 외부 애플리케이션에 작성하려면 꽤 많은 코드가 필요합니다. BizTalk Server 2006 R2의 BAM WF 인터셉터에서는 코드를 수정하지 않고도 BAM용 WF 워크플로를 보다 간단하게 계측할 수 있는 기능을 제공합니다. BAM 인터셉터를 사용하면 WF 또는 WCF 솔루션을 다시 컴파일하지 않고 비즈니스 프로세스를 추적할 수 있습니다. 통합은 구성 파일을 통해 수행됩니다.

WF SDK용 BizTalk Server 2006 확장

WF SDK용 BizTalk Server 2006 확장은 TechEd 2007에서 발표되고 데모되었습니다. 이 SDK는 BizTalk Server 2006에서 WF 워크플로를 호스팅하는 간단한 메커니즘을 제공합니다. 이 도구는 현재 WF 워크플로를 빌드하고 해당 워크플로의 강력하고 확장 가능한 호스팅을 달성할 수 있는 쉬운 방법을 찾고 있는 .NET 개발자가 사용하기 위한 것입니다.

SDK는 BizTalk Server 2006을 통해 메시지를 수신하고 보내기 위해 WF 워크플로 내에서 사용할 수 있는 두 가지 사용자 지정 WF 활동(btsReceive 활동 및 btsSend 작업)을 제공합니다. 개발자는 인바운드 및 아웃바운드 메시지에 대한 WCF DataContracts 정의하고 ServiceContract 정의하여 메시지 교환 패턴을 정의합니다. 그림 6과 같이 WF 워크플로 내에서 btsReceive 및 btsSend 작업은 정의된 ServiceContract사용하도록 구성됩니다.

그림 6. 정의된 ServiceContract에서 사용할 btsReceive 및 btsSend 작업

WF 워크플로가 완료되고 컴파일되면 워크플로 프로젝트를 마우스 오른쪽 단추로 클릭하고 오케스트레이션 생성 선택하여 WF 워크플로를 시작하고 BizTalk Server 2006 메시지를 양방향으로 라우팅하는 래퍼 오케스트레이션을 자동으로 생성합니다(그림 7 참조).

자동 생성된 래퍼 오케스트레이션에는 ServiceContract정의된 메시지에 대한 스키마가 포함됩니다. BizTalk Server 2006 메시지를 수신하고, 워크플로 인스턴스를 만들고 시작하고, 워크플로 인스턴스에 인바운드 메시지를 전달하고, 아웃바운드 메시지를 수신하고, BizTalk Server 2006 메시징 엔진으로 다시 전달하기 위한 BizTalk Server 오케스트레이션 셰이프 및 코드도 포함되어 있습니다. WF 워크플로의 호스팅을 완료하려면 래퍼 오케스트레이션을 컴파일 및 배포하고 일반적인 BizTalk Server 2006 메커니즘을 사용하여 바인딩하면 됩니다.

그림 7. 래퍼 오케스트레이션 자동 생성

BizTalk Server 2006 for WF 워크플로의 강력하고 확장 가능한 호스팅 메커니즘을 활용하는 것 외에도 BizTalk Server 2006 Extensions for WF SDK를 사용하면 BizTalk Server 2006 메시징 인프라를 활용할 수 있습니다. 따라서 BizTalk Server 2006으로 메시지를 가져오고 나가는 데 사용할 수 있는 많은 어댑터와 매핑 기능을 비롯한 파이프라인 처리를 활용할 수 있습니다.

WF SDK용 BizTalk Server 2006 확장은 BizTalk Server 2006을 적절한 도구로 식별한 시나리오에서 오케스트레이션을 대체하는 것이 아니라 WF 개발자가 BizTalk Server 2006 위에 워크플로를 배포할 수 있도록 하는 도구로 사용해야 합니다. 오케스트레이션에 래핑될 때 작동하지 않는 일부 WF 셰이프가 있습니다. WF SDK용 BizTalk Server 2006 확장을 사용하여 BizTalk Server 2006 내에서 WF 워크플로를 호스팅하는 것은 네이티브 오케스트레이션과 동일한 호스팅 동작을 제공하지 않기 때문입니다. SDK에는 이러한 차이점을 간략하게 설명하는 FAQ 목록(빠른 시작 가이드에 포함됨)이 있습니다.

결론

BizTalk Server 2006 및 Windows Workflow Foundation은 애플리케이션 및 엔터프라이즈 통합 워크플로 범주에서 워크플로 솔루션을 구현하기 위한 Microsoft의 기본 도구입니다. 프로젝트에 적합한 항목을 선택하려면 먼저 대상으로 지정하는 워크플로 시나리오를 식별해야 합니다.

다음으로, 그림 8의 표를 사용하여 시나리오에 권장되는 워크플로 기술을 확인합니다. 애플리케이션 내 워크플로의 경우 WF를 사용하는 것이 좋습니다. 대부분의 서버 기반 비즈니스 프로세스 및 B2B 시나리오의 경우 BizTalk Server 2006을 사용하는 것이 좋습니다.

그림 8. 시나리오별 워크플로 기술

장기 실행 비즈니스 프로세스 및 웹 서비스 집계 시나리오 모두에 대해 두 기술을 모두 적용할 수 있습니다. 이러한 시나리오의 경우 조직의 현재 및 단기 대상 APIO 프로필을 평가해야 합니다. 고급 또는 동적 프로필로 이동하거나 이동하는 조직은 이러한 시나리오에 BizTalk Server 2006을 사용해야 합니다. 기본 및 표준 프로필의 조직은 이러한 시나리오에 대해 WF를 효과적으로 사용할 수 있습니다.

마지막으로 BizTalk Server 2006 및 WF의 제품 로드맵을 기준으로 솔루션의 릴리스 날짜 및 원하는 수명을 고려해야 합니다. 이 프레임워크와 이 문서의 지침을 사용하여 프로젝트에 적합한 워크플로를 선택할 수 있어야 합니다.

추가

BizTalk Server 2006 및 WF에 대한 오해 해소

다음은 WF 및 BizTalk Server 2006에 대한 일반적인 오해와 이를 해소하는 데 사용하는 명확한 인수입니다.

WF는 BizTalk Server 2006을 대체합니다.아니요. WF는 프로그래밍 워크플로를 위한 Microsoft의 "최신 및 가장 위대한" 제품이므로 BizTalk Server 2006에 익숙하지 않은 많은 사람들은 처음에 WF 릴리스로 사용되지 않는 것으로 가정합니다. 이 인상을 수정하기 위한 간단한 대답은 WF가 모든 종류의 워크플로를 빌드하기 위한 낮은 수준의 개발자 프레임워크인 반면 BizTalk Server 2006은 워크플로 시나리오의 특정 범주인 엔터프라이즈 통합에 대한 고급 기능을 갖춘 본격적인 서버 제품이라는 것입니다. (그림 1 참조)
WF는 이 기능의 작은 하위 집합인 워크플로 및 비즈니스 규칙만 제공합니다. WF는 BizTalk Server 2006에서 제공하는 다른 모든 기능이 필요하지 않은 시나리오에 대해 더 간단하고 비용 효율적인 솔루션일 수 있지만, BizTalk Server 2006이 지원하도록 설계된 핵심 엔터프라이즈 통합 시나리오에 BizTalk Server 2006을 대체하지는 않습니다.
BizTalk Server가 사라집니다.아니요. 유사한 오해는 WF가 미래의 워크플로 도구로 릴리스되었고 BizTalk Server가 아직 WF를 사용하도록 다시 작성되지 않았기 때문에 Microsoft는 더 이상 BizTalk Server에 투자하지 않으며 결국 새로운 WF 기반 제품으로 대체될 것이라는 인상입니다. 이것은 사실이 아닙니다. BizTalk Server는 매우 성공적인 제품이며, BizTalk Server가 대상으로 하는 엔터프라이즈 통합 영역은 Microsoft가 지원하기 위해 최선을 다하고 있는 영역입니다.
.NET Framework를 통해 BizTalk Server 2006을 선택해야 합니다.아니요. BizTalk Server 2006에 익숙하지 않은 .NET 개발자가 "순수" .NET을 사용한다는 이유로 BizTalk Server 2006을 통해 WF를 선택하는 것이 좋습니다. 그러나 이것은 실제로 유용한 기준이 아닙니다. BizTalk Server 2006 자체는 .NET Framework를 기반으로 합니다.
실제로 BizTalk Server 2006은 솔루션에 적용할 수 있는 200만 줄 이상의 .NET 코드를 나타내며, 처음부터 기능을 개발하는 데 드는 시간, 문제 및 비용을 절약할 수 있습니다. 또한 BizTalk Server 2006 프로그래밍 자체는 Microsoft Visual Studio .NET 내에서 수행되며 구성 요소는 .NET 어셈블리로 컴파일 및 배포됩니다. 또한 가장 중요한 BizTalk Server 2006 프로젝트는 BizTalk Server 2006 구성 요소를 사용자 지정 .NET 구성 요소와 결합합니다. 따라서 BizTalk Server 2006 개발은 외형 또는 다른 것이 아니라 특수한 .NET 개발로 간주되어야 합니다.
진짜 문제는 BizTalk Server 2006 기능이 라이선스 비용을 정당화하기 위해 특정 워크플로 시나리오에 충분한 가치를 제공하는지 여부입니다. 사진을 걸기 위해 썰매 망치를 사용하고 싶지는 않습니다. 큰 바위를 분쇄하기 위해 목수의 망치를 사용하고 싶지도 않습니다.
가장 많은 기능이 우선합니다.가난한 선택. WF의 세분화된 기능을 BizTalk Server 2006과 비교하는 기능 매트릭스를 만들 수 있습니다. 그러나 이 비교는 별로 도움이 되지 않습니다. BizTalk Server 2006에는 특히 엔터프라이즈 통합 공간을 대상으로 하는 많은 기능이 있습니다. 대상 시나리오가 아닌 경우 기능 비교는 의미가 없습니다. BizTalk Server 2006은 기능 확인란의 수와 관련하여 이길 수 있습니다. 그러나 이러한 기능이 대상으로 지정하는 워크플로 시나리오와 관련이 없는 경우 사과 대 오렌지 비교입니다.

승인을

폴 앤드류와 크리스 호록스, 그리고 이 기사를 검토해 주신 모든 분들께 감사드립니다.

추가 정보

"BizTalk Server 2006 R2 Extensions for Windows Workflow Foundation SDK V1": https://www.microsoft.com/downloads/details.aspx?FamilyID=b701c00f-cdc1-4edb-a975-b9412263ec6e& displaylang=en
Paul Andrew의 블로그(SDK 개요 제공): https://blogs.msdn.com/pandrew/archive/2007/11/01/just-released-biztalk-server-2006-extensions-for-windows-workflow-foundation-sdk.aspx
WF용 MSDN 포럼(SDK에 대해 논의할 수 있음): https://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=122& SiteID=1

작성자 정보

Kent Brown은 뉴욕시의 Microsoft Gold Certified 컨설팅 파트너인 Twentysix New York에서 엔터프라이즈 통합 연습의 이사 겸 수석 설계자입니다. 그는 2000년에 시작된 이래 BizTalk Server에 대해 흥분해 왔으며, 지난 7년 동안 제품에서 전도사 역할을 해왔습니다. Kent는 Microsoft BizTalk Virtual Technical Specialist Team의 멤버이자 Microsoft Connected Systems 개발자 MVP입니다. 그는 뉴욕 커넥티드 시스템 사용자 그룹(http://www.NYCCSUG.org)의 창립자이자 리더입니다.