워크 플로 서비스를 Windows 서비스로 호스팅 할 수 있습니까?

Question

서비스로 노출되는 워크 플로 (워크 플로 서비스)가 필요한 로깅 응용 프로그램을 작성하고 있습니다. 우리는 이것을 Windows 서비스로 호스트하고자합니다 (IIS에서 .svc 파일로 워크 플로 서비스를 호스트하지 않으려 고합니다). Windows 서비스로 사용하는 또 다른 이유는 명명 된 파이프를 통해 서비스와 통신 할 수 있기 때문입니다.

IIS에서 호스팅하지 않고 명명 된 파이프를 통해 워크 플로 서비스를 노출 할 수 있습니까?

Answer 1

예 가능합니다. 자신 만의 서비스를 만들어야합니다. MSDN의 Hosting and Consuming WCF Services, 특히 섹션의 Windows 서비스 호스팅을 참조하십시오.

Answer 2

예, 가능합니다. 적어도 Workflow 4 Release Candidate에서 많은 성과를 거두었습니다.

고려,

// a generic self-hosted workflow service hosting thingy. Actual 
// implementation should contain more logging and thread safety, this 
// is an abbreviated version ;) 
public class WorkflowHost 
{ 

    // NOTE: with Workflow, it helps to maintain a concept of 
    // Workflow definition [the Activity or WorkflowService from 
    // a designer] and a Workflow instance [what is running within 
    // WorkflowInvoker, WorkflowApplication, WorkflowServiceHost]. 
    // a definition may be used to generate an instance. an instance 
    // contains run-time state and cannot be recycled into a new 
    // instance. therefore, to repeatedly re-host a WorkflowService 
    // we need to maintain references to original definitions and 
    // actual instances. ergo services and hosts maps 
    // 
    // if you are special purpose and require support for one and 
    // only one service and endpoint\uri, then you may reduce this 
    // to a simple tuple of Uri, WorkflowService, WorkflowServiceHost 

    // services represents a definition of hosted services 
    private readonly Dictionary<Uri, WorkflowService> _services = 
     new Dictionary<Uri, WorkflowService>(); 

    // hosts represents actual running instances of services 
    private readonly Dictionary<Uri, WorkflowServiceHost> _hosts = 
     new Dictionary<Uri, WorkflowServiceHost>(); 

    // constructor accepts a map of Uris (ie service endpoints) to 
    // workflow service definitions 
    public WorkflowHost (IDictionary<Uri, WorkflowService> services) 
    { 
     foreach (KeyValuePair<Uri, WorkflowService> servicePair in services) 
     { 
      _services.Add (servicePair.Key, servicePair.Value); 
     } 
    } 

    // have your windows service invoke this to start hosting 
    public void Start() 
    { 
     if (_hosts.Count > 0) 
     { 
      Stop(); 
     } 

     foreach (KeyValuePair<Uri, WorkflowService> servicePair in _services) 
     { 
      WorkflowService service = servicePair.Value; 
      Uri uri = servicePair.Key; 
      WorkflowServiceHost host = new WorkflowServiceHost (service, uri); 

      host.Open(); 

      _hosts.Add (uri, host); 
     } 
    } 

    // have your windows service invoke this to stop hosting 
    public void Stop() 
    { 
     if (_hosts.Count > 0) 
     { 
      foreach (KeyValuePair<Uri, WorkflowService> servicePair in 
       _services) 
      { 
       WorkflowService service = servicePair.Value; 
       Uri uri = servicePair.Key; 

       IDisposable host = _hosts[uri]; 
       host.Dispose(); 
      } 

      _hosts.Clear(); 
     } 
    } 
} 

나는 엔드 포인트 구성의 App.config 표준 WCF 서비스 구성 섹션을 통해 설정 될 수있다 생각합니다. 개인적으로 워크 플로 실험에서 기본 전송 계층의 변경을 시도하지 않았습니다.

위의 코드는 일반적인 순수 호스팅 클래스를 나타냅니다 (즉, WorkflowServices 자체 호스트). 이를 통해 콘솔, WinForm, WPF 또는 Windows 서비스 응용 프로그램조차도이 호스팅 기능을 재사용 할 수 있습니다. 다음은 당신이 이미 WorkflowServices가 자신의 워크 플로 사촌 같은 일류 XAML 클래스가 아니라는 것을 알 수 VS2010RC에서 WorkflowServices와 바이올린을 경우 우리의 호스트 클래스

// windows service. personally i would abstract service behind 
// an interface and inject it, but again, for brevity ;) 
public partial class WorkflowWindowsService : ServiceBase 
{ 
    WorkflowHost _host; 

    public WorkflowWindowsService() 
    { 
     InitializeComponent(); 

     Dictionary<Uri, WorkflowService> services = 
      new Dictionary<Uri, WorkflowService>(); 

     // do your service loading ... 

     // create host 
     _host = new WorkflowHost (services); 
    } 

    protected override void OnStart(string[] args) 
    { 
     _host.Start(); 
    } 

    protected override void OnStop() 
    { 
     _host.Stop(); 
    } 
} 

을 활용하는 윈도우 서비스입니다. 대신 확장자가 .xamlx 인 느슨한 Xaml 파일로 저장됩니다. 우리의 유일한 옵션은 실행 시간에 WorkflowService를로드

• 부터 순수 XAML 마크 업을 읽을하기 때문에 [내가 아는]를 선언 유형으로 인식되지 않습니다 WorkflowServices에 대한 디자인 타임 인텔리 지원은 없다. xamlx 직접
• 는 다른 소스 [포함 된 문자열, 자원 또는 다른 소스]

어느 쪽이든에서 순수 XAML 마크 업을 읽어 파일, 우리는 마크 업을 해석하고 WorkflowService 정의를 작성해야합니다. 다음은 [파일 이름 또는 마크 업일 수있는] 문자열을 WorkflowService로 변환합니다. Keeners는이 프로세스와 워크 플로 마크 업을 워크 플로 정의로 변환하는 프로세스간에 차이점이 있음을 알 수 있습니다.

// converts a string value [either pure xaml or filename] to a 
// WorkflowService definition 
public WorkflowService ToWorkflowService (string value) 
{ 
    WorkflowService service = null; 

    // 1. assume value is Xaml 
    string xaml = value; 

    // 2. if value is file path, 
    if (File.Exists (value)) 
    { 
     // 2a. read contents to xaml 
     xaml = File.ReadAllText (value); 
    } 

    // 3. build service 
    using (StringReader xamlReader = new StringReader (xaml)) 
    { 
     object untypedService = null; 

     // NOTE: XamlServices, NOT ActivityXamlServices 
     untypedService = XamlServices.Load (xamlReader); 

     if (untypedService is WorkflowService) 
     { 
      service = (WorkflowService)(untypedService); 
     } 
     else 
     { 
      throw new ArgumentException (
       string.Format (
       "Unexpected error reading WorkflowService from " + 
       "value [{0}] and Xaml [{1}]. Xaml does not define a " + 
       "WorkflowService, but an instance of [{2}].", 
       value, 
       xaml, 
       untypedService.GetType())); 
     } 
    } 

    return service; 
}