Some Questions/complaints From The Field

1) Unforgiveablity - this is an advantage and disadvantage of service broker. The advantage is that it forces developers to be precise with the formation and decomposition of messages as well as forcing disciplined use of transactions. The disadvantages lie in the same. With the slightest error in dialog management, the transaction log grows out of control. With any solution that is incorporating SQL Express (and thanks to the limitations for surfacing the problems), the transaction log, invariably - at some point - grows uncontrollably, especially if you have a web application monitoring queues. There really needs to be better checkpoints and obeyance of normal SQL Server contraints. It seems that sometimes service broker has a mind of its own and takes over not only the SQL instance, but the disk and everything else.
2) Administration/Management capabilities - as far as I am concerned, these are non-existent. I find it hard to believe that I can't even script my service broker objects using the native management studio scripting tool. Its ridiculous that - in an enterprise system - I have to manually script out scores of service broker objects. The operations group agrees with me and this does nothing to enhance the reputation of SQL Server as an enterprise player. You can't produce a SP that provides these capabilities? I have had to build in diagnostics and recovery stats by way of user tables that collect and analyze service broker message activity.
3) Internal Activity - what the hell is going on in these internal tables? I can't find any documentation about the use of tempdb or anything else. Please provide something explaining where all the activity occurs and where space is consumed. This is kind of important when operating on restricted platforms, like SQL Express.
4) Locking - seems like you need a more granular locking strategy. This is just conjecture, but it seems when service broker wants; service broker takes. How about letting the application architect/developer decide when service broker takes?
5) Dialog Pool Management - this is very complex to implement and almost all "real" applications need it. You need to provide an out-of-the-box, starter implementation because this leads to problems mentioned in #1. Remember how the VS application wizard killed the Borland dev environment? Well, SQL Server needs an equivalent. Stop making us write the same thing over and over again; and stop making me write the same queries over and over again.
6) Evangelists - Most people don't even know what service broker is, and it makes it a very hard sell. Even experienced SQL developers are not sure how and why it should be used. I have interviewed over 20 pretty strong SQL candidates over the last year and I can't name one that new ANYTHING about service broker.
7) Guidelines for Conversation Cleanup - well, it's a fact of life - we have to cleanup bad conversation handles from time to time. OK, maybe this wouldn't happen if we didn't have careless or error-prone programming, but we do. What is the proper way to cleanup dialogs between two endpoints? How about some sample queries to run on the initiator and the target? Or even an english language description of how to go about cleaning up and starting over with conversations that have gotten into a "bad" state?
8) UDP/Broadcast/Multicast Messages - This is a pretty big problem in my opinion. I can't believe this has not been added to 2008 (or at least, I did not see it in the feature list). Roger Wolter said it would be in the next version when the 2005 articles were written. So, I am supposed to keep cursoring through message endpoints and tricking up the TRANSPORT route to achieve what a broadcast implementation could achieve?

I guess thats enough for now. I look forward to the responses.