SQL Server - Service Broker
The sleeper has awakened
"order has shipped."
My copy of Bob and Dan's "A Developer's Guide to SQL Server 2005 has finally departed from whatever cave Amazon loaded them into. Can't wait to see how different it is. Its going to be a lot of reading too, its accompanied by Johnson's ADO.NET Advanced Topics book that I'm also looking forward too.
Is it time for me to take up the writing effort again? Maybe. I've got ideas, but what would you be interested in?
Doh! Sorry to be late getting this on the wire but the Heartland Developers' Conference for 2006 is has been announced. This year its in Omaha and runs from 26 October and 27 October. Hopefully I won't find myself in China again...
In its 3rd year, HDC06 is the largest independent annual professional Microsoft development conference in the nation, organized by user groups, and focused on .NET development and other emerging Microsoft technologies. HDC provides regional developers the opportunity to experience sessions usually reserved for Tech-Ed and PDC at a much lower cost while retaining the same nationally known presenters. Over 2 days, 23 sessions, 2 tracks, and several networking opportunities, HDC06 is where you’re find top knowledge experts that can prepare you for next level development.
For only $125 Early Bird/$175 standard, each Attendee Pass includes:
1 Conference pass to 2 keynotes and all 23 ninety minute sessions
- Meals including breakfast, lunch, snacks, and coffee breaks
- Access to the “Developer Lounge” expo and activity center
- Wireless internet access throughout conference area
- Pre conference networking party including drinks and food
- Thursday night “Developer Jam” including food, drink, and a casino for prizes!
- Attendee Kit and a chance to win a monster 64 Bit Alienware computer
The speaker list is looking awesome too: Microsoft's own Jeff Brand, Don Bryner and Jacob Cynamon. MVPs Dave Donaldson, Robert Hurlbut, Rocky Lhotka, Javier Lozano and Andrew Troelsen and community rockstars Craig Utley, Phil Wolfe, Robert Boedigheimer, Tim Gifford, Matt Milner and Nick Parker. I'm planning of giving a couple of talks on SQL Server 2005 for Developers.
Register here. And remember, we're talking a mere $125 one of the best Microsoft-focused technical conferences in the Midwest.
As usual, some of the best questions come from the newsgroups. And yet again, there was one that piqued by attention. The question essentially boiled down to “can you put a trigger on a login?” That is, the questioner wanted to execute some arbitrary T-SQL code whenever a user logged into a given instance of SQL Server. I’m not sure how you’d go about doing this in SQL Server 2000, but in 2005, two features make this possible – if you don’t mind building a bit of your own plumbing. These features are EVENT NOTIFICATIONS and the Service Broker.
Event Notifications are essentially fixtures that your create – using T-SQL – that allows SQL Server to dispatch messages about system events like logins, data definition language statements, and some trace events to Service Broker Services and Queues. The Service Broker Service acts as an address for the messages, while the Queue holds the messages until some a process like a Stored Procedure process them. Some number of instances of that Stored Procedure will be spawned by a process called Activation when a message arrives in a Queue. So these two features work together to deliver information about system events to a stored procedure that gets executed in response to that event, much like how a trigger gets fired in response to events.
What started out as fairly short post turned into a fairly long item, so I've contued this over here, while the annotated source code (with bonus features) is over here.
As Greg and Wally have reported, I've been thinking about bringing back Take Outs as a PodCast. I'm pleased to announce with the the hosting support offered by Steve Wynkoop of SSWUG, its now a reality. The need-to-knows:
The RSS feed: http://feeds.feedburner.com/sswugorgradio
iTunes friendly feed: http://feeds.feedburner.com/SswugorgRadio?format=pcast
Episode one show notes and download file.
Let's roll!
The start of the new year always makes me think I want to do new things. This year I'm trying to eat more healthily, drink less and blog more. While you probably don't care so much about the first two of those, you're probably interested in the third. Afterall, consider what your doing right now...
Effective today, I'm shifting my blog focus from SQLJunkies (what you're reading right now) over to GeeksWithBlogs. Here's the new feeds and their RSS URLs.
I'll keep posting references to stuff about .NET and SQL Server on this site for some time to come, of course.
Just in case you live under a rock (like I seem to have been doing recently), my DevelopMentor cohort Niels Berglund has shipped updated versions of his custom SqlClr Project and his GUI for Service Broker. Go check 'em out.
Justin King asks a really good question: Where are all the SQL Server 2005 books?. Well Justin, there's five I can recommend off the top of my head:
- "A First Look At SQL Server 2005 For Developers" by Beauchemin, Sullivan and Bergland.
- "Introducing Microsoft SQL Server 2005 for Developers" by DeBetta
- "The Rational Guide to SQL Server 2005 Service Broker Beta Preview" by Wolter
- "The Rational Guide to Scripting SQL Server 2005 Integration Services" by Farmer
- "Microsoft SQL Server 2005 New Features" by Otey
That said, there's a reason you don't see one of my books on this list. I've done my share of writing for beta books in the past. And I think I've half-jokingly, half-honestly said that one of the best ways for me to learn a technology is write a book about it. There's a couple of problems with doing this of course. First and foremost, you really that to be an expert in the domains where where the technology gets used in practice in order to find all of the things that the best books talk about. Folks like Alex Homer, David Sussman, Dan Sullivan, Niels Bergland, Bob Beauchemin, Roger Wolter and Donald Farmer have always impressed me by being able to show me ways to apply the new technologies in terms of problems that I understand today. That's something that I think I have to improve on. Second, and probably more germane to your question is the very nature of SQL Server 2005 its self. While it pretty easy to explain the technology as it is and as it applies, its much harder to fully understand, appreciate and communicate one something like the XML datatype really affects the preformance of a Data Warehouse on the whole. Lastly, SQL Server 2005 is a massive and highly integrated platform. The sheer number of featuers and changes makes groking all of it difficult enough. Each released Beta and CTP has introduced a huge number of delta to keep track of as well. So while I envy Dan, Niels and Bob for the tremedious success they've had with "A First Look At SQL Server 2005 for Developers", for example, I'm glad its them doing it rather than me.
I suspect that a lot of other authors have decided that they too would rather wait for the bits to settle down and then spend time doing the kind of exhustive research on them rather than engage in that work early. I see value in both approaches: We definitely need "betabooks" to help prime the pump, and we need more comprehensive books based on production practices with the final bits to tell that part of the story.
One other thing to keep in mind is that SQL Server 2005 isn't like .NET in that the product already has a deep and strong production basis that isn't going to be as easily adopted. One of the real draws for me with ASP.NET was that it took almost no server side or highly specialized adminstrator knowledge to implement quick. SQL Server 2005 is 180-degrees opposite of that and as result, I think SQL Server 2005 gives authors more "shelf-life" and time write good books.
Keith Brown has a meaty posting on his blog talking about channel security for SQL Server. The highlight, at least for me, is this:
Why am I bugged by this? Why don't I just use SSL and get in line with everyone else? Because setting up SSL connections is considerably slower than setting up Kerberos connections (think public key operations in SSL versus purely symmetrical operations with Kerb), and it requires certificates and PKI where Kerberos is already built right in to my domain infrastructure.
I really like the post, but there is something that bugs me about it. It feels like he's complaining about the glass being half-empty.
Sure, I'll go along with his contention that in your in a fully Active Directory integrated environment that using the Kerberos would be a great solution and for exactly the reason he gives. But frankly, I don't see Microsoft changing their point-of-view that SSL is a better choice, and no, I don't expect the story for Yukon (SQL Server 2005) will make Keith any happier. These are best demonstrated when you think about situations where identity isn't shared, but trust explicitly is. And what kinds of situations are those?
- SQL Server Replication of data between business partners who may or may not have their own Active Directories. In this case, the need to exchange data securely is easily understandable, but the sharing of an identity as the basis of key and ticket exchange becomes problematic. However, a good PKI implementation partial solves this problem by enabling the easy exchange and validation of certificates.
- Data exchange between Compact Device applications and domain member SQL Servers. The typical Compact Device usually lacks the ability to participate in the Active Directory and thus cannot drive the Windows Integrated context needed for such a login. However, these devices typically do support SSL out-of-the box.
- SQL Server 2005 Service Broker applications distributed over many hosting domains. One of the reasons that Service Broker appeals to me is that in integrated business scenarios, different parts of an application can be hosted on servers in mutually non-trusting domains. For example, a TeleServices company may "own" and host service programs that deal with the generation of sales orders, while a second company "owns" the service programs for fulfillment and third "owns" the service programs for executing the financial aspects of an order. Sharing an Active Directory between these three parties might prove to be both expensive and difficult to manage correctly. However, since Service Broker uses certificate authentication of endpoints, this should be much easier and less expensive to achieve.
These cases demonstrate how SQL Server transcends many of Microsoft's other products in terms of secured inter-operation by specifically avoiding being overly dependent on the Network Operation System for security. So am I saying that Keith's desire better integration with Kerberos security is invalid? Not at all -- it has obvious value in many cases. But I would say that I, for one, am glad that the SQL Servet Team embraces SSL and puts their focus on that technology. Its a great example of how flexible SQL Server can be, albeit with some performance hit. Seems like a small price to pay to be able to achieve this kind of flexibility with a minimally shared surface area. I'd rather have Microsoft work on enhancing the reach and performance of SSL rather than expend that effort on making Kerberos work better, at least as far as SQL Server goes.
Then again, maybe I'm just used to seeing the glass as half-full instead of half-empty.
There's clearly nothing that is so granular, so surgical, so "Einstein"
level elsewhere in the .NET stack. I get that. Its the Light Saber,,
the Bier Lambic, the Cassoulet Toulousain equivalent, if you will, of
the WinFX world. Naturally, the "Elvi" are bound to love it--
once they grok enough of it to sing about it -- since its hip, new and
happening. And it gives them endless ways to use the same n-many
nuggets of knowledge to solve just about any enterprise space problem.
And it certainly looks like its fun to talk about.
So, sure for them, its great. But what about Morts like me. What's in
Indigo for us? And why would we choose to engage in effort of using
and maintaining it over something like BizTalk or SQL Server Service
Broker and the SOAP bits we get using SQLCLR? Sure, its great that it
reduces the amount of code required to write a reliable messaging
application down from tens of thousands down to a few hundred. And
that's great if you're writing those frameworks, I guess. But what
other tools, tricks or abilities does it bring to the table?
That's why I agree with Jon Flanders (and indirectly Don Box) that
BizTalk is an extremely useful tool for the greater majority of
Professional Developers to grok, at least today. So are SSB and SQLCLR
for the Morts who can use them.
So, does anybody care to break Indigo down for me and tell me, from a Mort's POV, why its worth learning today?
And yes, I'm serious. While I have no aspirations to become an Indigo
"Einstein," I wouldn't mind being able to "Elvis: about it in the data
access and management space.
So you probably saw those black-shirted guys (one of them was Mike
Hall) driving around on Segways at TechEd 2005, but what were they
doing? Interview folks! and
Peter DeBetta,
Rick Heiges and I got our
seven minutes and 52 seconds of fame with them. Here's
the video
(Sorry, Windows Format only... Grrr...) and the
source posting.
And for what its worth, here's the new features of SQL Server 2005 Mobile Edition:
- Direct usabilty from SSMS
- Upgraded to a cost-based query optimizer
- Force feed Mobile databases with BCP
- Multi-user support
- Configurable compression levels of database files with auto-shrink support
- Managed APIs for synchronization via merge replication
- Exposes the synchronization progress status through a managed API
Much more information on it at http://www.microsoft.com/sql/ce/productinfo/SQLMobile.asp
Isn't community great?!
Some more links for Atlanta Class
In class today, we started off by talking about SQL Server 2005's Service Broker. Here's a few additional resources that I think help understanding Service Broker a bit easier:
If are looking for the inkboard drawing, here's a photo of it. I'll try to make it available as a Visio in the future.
So it is no big secret that I'm a big fan of Bob for a lot of reasons, but that aside, if your not reading his blog on a regular basis, you're missing out. Since he's had a couple of days out of the class room, Bob's posted a number of things that affect all of use Yukon users. Here's an example:
- Here's a post that refers to Pablo Castro's posting on the unification of SqlServer and SqlClient namespaces. Technically, I'm okay with the idea, but psychologically, I still wish they were two different namespaces.
- Here's some discussion of the updates to DROP ASSEMBLY. One thing that I've seen folks struggling with is chained assembly getting loaded into SQL Server, so this really is an improvement.
- Finally, a week ago in the SQLCLR newsgroup, I said that J# isn't a supported language for building objects and pretty much left an answer at that. Turns out while my answer was right, what unsupported really means isn't exactly what you might expect it to mean. That said, because you essentially have to register such an assembly as UNSAFE to use it (regardless of how safe it may or may not be), I still don't recommend going down the J# if its possible to achieve the same result easily with a support language like C#.
- Bob also details some developer productivity enhancements to Service Broker. I really like the default ideas -- should make programming against the SSB that much easier. The poison message handling stuff is cool too and its certainly something you'll want to keep in mind.
Concise, complete and to the point. Somebody give this man a raise!
Thank you yet again, Mr. Desai.
So how do you use InfoPath and SQL Server 2005 Service Broker together? Rushi Desai to the rescue: Integerating InfoPath with SQL Server 2005.
Man this guy is cranking out the good stuff!
Its not so much that I've lazy the last few days... but I've built up a pile of things I wanted to talk about:
- Rushi Desai talks about a Framework that simplifies building Service Broker Apps. Way cool, I think.
- Michael Rys talks about the updated XQuery drafts. Something I'm not sure I get quite yet about the update spec is why Isolation is a should and not a must.
- Moshe Eshel ask a good question SQL Server 2000. How do you make composite types work with VB6.
- There's a lot of feedback about Binary XML from Mark Fussell. I'm still trying to sort out exactly how I feel about that topic. There's lots of reasons to do it, I think, but yes, everybody is either going to have to support whatever comes out as a standard or its not going to be as successfull as it should.
- I think there's a a fine grain of difference between "Contract First" thinking and what Dare talks as having problems when it comes to implementations of it. I do think he's right though: when you think "Contract First" you do have to leave behind specifics of a toolkit and focus on the abstracts to be successful. That's not a bad thing.
- Anybody want to pay for me to go to Insbrook in June? Why would I want to? Frameworks for Semantics in Web Services. Now that's progress on something useful, I think.
- DonXML writes up a pretty good summary of the whole Send Messages Not Serialized Object Graphs discussion that's been going on.
- For now for something completely different: Flash and Databases in a few easy steps. Nice.
- Jeff Brand's mandatory where to go get more on Indigo posting.
- John Tobler brought up the XSD Inference Utility which is a nice alternative to XSD.EXE, especially since it offers an API for doing it.
- Dare talks about Tim Ewalds three Web Services stacks. Maybe I'm just too Joe Average, but it seems to me that 75% of the problems I need to solve I can with Plain Old Soap and the other 25% can be done with WS-*. Not sure why I choose to limit myself to a specific toolkit when I didn't need to.
- Aaron Weiker is quickly turning into one of my favorite East Coast Geeks. Why? He finds cool tools.
- All you could want to know today about WinFX
- Don't like how Reporting Services renders a report? Write your own custom rendering stuff.
- I like Phil Wolfe, even when he say crazy stuff like do do remoting.. Crazy talk, man, carzy.
- Rocky frames Indigo as n-tier client server? Not really but makes a good case for why that's a concern.
His Instant Messenger display name includes some very valuable advice:
Send Messages Not Serialized Object Graphs
Jeff Brand posts a groan about the possibility of Yet Another Workflow Framework (YAWF). And he wonders if anybody remembers “Grizzly,” the code name for a workflow system that used SQL Server 7.0 as the back end.
Continues here.
Rushi, a developer on the SQL Engine Team, offers a quick introduction to SQL Server 2005 Service Broker and some reasons to use it.
I've been reading Rocky Lhotka's posts from today on Remoting, SOA as RPC and Services having tiers. I think he's right about a lot of what he has to say and that got me thinking about SQL Server 2005's Web Services and Service Broker (again).
One of the key points I took out Rocky's first post was