Workflow Service custom tracking participant that talks to a client-side endpoint(s)?

Question

I'm at the investigative stage for Workflow Service and WPF.

Having State Machine WF Service hosted in IIS and one or more WPF clients talking to the WF Service sounds reasonable choice so far.

However, although days of reading and research it isn't clear to me what would be the best strategy for tracking the transfer between states from WPF app.

There're numerous samples of tracking participants but most of them are based on One process scenario.

So I am thinking of a structure as below.

1. A server-side WCF operation that any client calls to register its client-side endpoint
2. A custom tracking participant that goes through all registered client-side endpoints and sends TrackingRecord at it's Track() method.

Advantage of this approach is that it allows real time update of the states without extra layers like ETW. Another advantage is that it allows decoupling of the logic (or maybe model layer) from the presentation layer.

Can anyone share the opinion over the above structure? I would also welcome any suggestions for achieving the goal.

---

[EDIT] To make my idea above more detailed and clear, below steps would be a typical usage.

1) (WPF client) contains and opens a WCF endpoint for receiving TrackRecords.

2) (WF Service) opens a WCF operation (or a simple WF instance with a Receive message) that registers client-side address to an internal store.

3) (WF Service) a custom tracking participant is created and added that will send TrackingRecord to the registered clients' endpoints.

4) (client) connects to the above service and hands out client-side endpoint mentioned at step 1 and consequently receives TrackingRecords.

---

[ EDIT 2 ]

To put my goal in simple terms, I'd like to know

1) the most efficient way of tracking the StateMachine's state on a WF Service (IIS) + WPF or any types of client app through TrackingParticipant.

2) if my suggestion can be improved

Meanwhile, I have implemented this and works good so far. I also added MvvM Light framework's messaging feature at the client-side so that it propagate the received message to the models easily.

Answer 1

You might take a look at SignalR instead of trying to force WCF to become a pub/sub platform which is not it's strength. There is an example on my blog with the visual tracking example with the tracking participant split out from the tracking application so it's not all in one process. That blog also has links to two other blogs where similar things were done, but all using a messaging architecture more suitable to events like this.

http://panmanphil.wordpress.com/2012/11/05/slides-and-sample-from-the-chippewa-valley-code-camp/

Answer 2

There is an existing mechanism that wraps a lot of the functionality that you are suggesting (If I understand your needs correctly). If you need to utilize a WCF service to communicate in a bidirectional way (i.e. PUSH data to connected clients) I would suggest leveraging the PollingDuplex Binding.

I have used PollingDuplex in the past with various Silverlight clients to exchange data, and I have read articles like this one describing the steps to produce the same behavior in WPF space.

This approach will automate much of the endpoint registration and tracking logic that you apparently are thinking of doing manually.

I hope this helps.