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.
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.
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/