I'm looking for a bit more detail on the nature of the WF Subscriber.  I've reviewed the information in the admin guide under How Does It Work, and am sufficiently familiar with the Subscriber's usage of MSMQ to asynchronously communicate event/rule data to the WF Server leading to the execution of Workflows. 

What we'd like to understand better is the nature of the communication of notifications from the repository server to the WF Subscriber.... referenced in the How Does It Work material as simply "WF Subscriber signs up for notifications from LFS"

What exactly is the nature of communicating these notifications? Are they pushed from LFS to WF Subscriber?  I see no web services exposed by WF Subscriber, or any TCP listeners bound to the WF Subscriber process when running... so it doesn't appear LFS initiates a connection to the WF Subscriber to push over those notifications.  

When the subscriber is running, we see it initiates and maintains an active session to a monitored repository under the WFUSER$ account... listed in active sessions along with all other active client connections.  Are the notifications passed over that connection? 

Stopping the Workflow Subscriber for a period of time and then starting it, notifications for events that occurred while the subscriber was down are processed when it comes up... which indicates those notifications are queued and communicated asynchronously to ensure no missed notifications.  But MSMQ doesn't appear to be in play on the LFS side... so it's not used as a transport from the LFS Server to WF Subscriber. 

So... we're left wondering what are the underlying queuing and communication mechanisms involved in getting notifications data from LFS to WF Subscriber?