We only need a single Q and Service. Message types, contracts, routes, etc are not needed. The "DoSomething" procedure is basically whatever you want to execute every x seconds.
I created a "Start Tickling" procedure. This simply looks to see if I have an existing conversation (you only need one) for the Tickler. If not, a create a conversation and TIMER against that conversation. That sends a message to the TicklerQ.
The Tickler Q is an activated Q. This is the stored proc that runs when a message is enqueued. Here we simply RECEIVE the message and execute our DoSomething procedure. Then we send another CONVERSATION TIMER (basically this is an infinite loop).
After we have all of the scaffolding in place (the Q, Service, activator proc, etc...we need to turn on ACTIVATION for the Q. We are now ready to seed the first TIMER using the StartTickling proc.
Again, I think this is a much more elegant solution then a SQL Agent job. Here I can run my procedure without having affinity to a job that will not get restored when I restore my db to another server. Tickling also picks up whenever the db is restored, comes back online after a restart, etc. A very elegant solution.
Dave Wentzel CONTENT sql server data architecture service broker