Talking to the Windows Service

Note: This is part of a series:
1. Talking WF (introduction)
2. Workflow Instance State Management
3. Workflow Communication and Workflow Communication Clarification
4. Hosting WF
more to come (error management).

The last post left us with the web application residing in IIS and WF hosted in a Windows Service. Separated like a divorced couple. Now we need to setup some communication between them. The means of choice? WCF of course. (There is a choice?)

I’m not going into too much details about WCF here as this series is devoted to WF and the documentation for WCF is considerably broader than the WF related information. For hosting of WCF in a Windows Service have a look at How to: Host a WCF Service in a Managed Windows Service. For a more elaborate example including WF Integrating Windows Workflow Foundation and Windows Communication Foundation will show you how to host the WF engine as service extension (gee, the service pattern again).

‘S’ervice or ‘s’ervice?

Let’s have a look at the architecture: What will become of our Windows Service if I attach a WCF interface to it? Will it become a Service in the SOA sense (capital ‘S’!)? Do we therefore need to set up HTTP bindings, WS-Security (my vacation is certainly important enough to be protected!)? Are we going to advertise the Service so that a customer can plug into it? Probably not. None of it. From a logical point of view the WF part is still part of the business logic of our application as the reason to separate it was purely technical. It will therefore become an internal service (see WebService? What do you mean, „WebService“?), lowercase ‘s’!.

WCF actually supports internal services quite well with the named pipe binding. It’s is a binary, efficient binding and it is restricted to one machine (the binding, not named pipes in general of course). This might rule out distributing the two parts on different machines, but seriously, we don‘t have that many employees (yet).
Windows actually also „supports“ that choice by making it very hard to choose HTTP instead. (The “very” stems from the fact that it’s hard to diagnose the reason for the problem. There is solution, though not a pretty one, all in the name of security.)

The fact that we factored the WF engine out of our web application was not intended to change the logical architecture more than necessary, i.e. the workflow is still part of our business logic:

However the physical architecture is somewhat different:

The danger here lies in misinterpreting the physical architecture as logical architecture. (It’s actually debateable whether the call to the Windows Service originates from the DAL or the BL. Don’t sweat it, it’s of no consequence.)

‘S’ervice?

The demand of our application is fulfilled, but let‘s think a bit more about the Service notion. What if I actually wanted a Service in the SOA sense, one that is publicly available?

In this case I would still propose the very same approach for the Windows Service and an accompanying web application. The web application would consist of a publicly available Service (WCF hosted in IIS, e.g. a Web Service), part of the presentation layer, that handled the communication with the caller (validation, security, versioning, ….). It would implement the service interface that was developed during the contracting phase. Internally it would talk, again using WCF, to the Windows Service, just like above. For a prototype SOA ecosystem based on this idea (and being a little more fleshed out) have a look at Security analysis on WCF for the German Gouvernment.

For a series about WF this post was kind of a diversion. Yet I think it is part of the architecture implied by the employment of WF, therefore I kept it in. The next post will look into robust processing, as promised in a previous post.

Quick! How many different notions of the word ‘Service’ did you count in this post? 😉

That’s all for now folks,
AJ.NET

Advertisement