Author: Ben

Well now, this little toolset sure looks interesting, if only for the code contained within. Some pre-built code to create Application Pools and such sure would be handy.

While Brian and I were trying to figure out what color is green’s opposite, he found a really cool color wheel written in Javascript. Handy!

So I sat through the MSDN webcast on SQL Server Service Broker, which is coming with 2005.  So here’s what I found out:

Service Broker is a platform for building async queued db apps.  It brings queues into T-SQL and supposed enables transactional message processing and reliable distributed async operations.  Not sure what that means yet.  First neat thing, queues are first class ideas.  You can send messages to queues and retrieve them from queues without a lot of effort.

Transactional message processing seems to mean exactly what it says.  Processing messages in a transactional manner.  It doesn’t seem to bleed out any further.  The atom here is sending a message or grabbing a message.

Reliable distributed async operations = we can reliably deliver messages remotely.

So far, sounds a lot like Tibco.

Message Integrity slide includes “Database Mirroring”.  What the heck is that?  Ah, new feature in Yukon.  Allows you fail over both the db and the queues.. Neat.  If it works.

Message Ordering:  they guarentee in-order delivery, even across transactions and multiple threads.  No word on multiple servers.  Hmmm.

Onto dialogs.  Logical connection between databases / services / etc.  Does not correspond to one physical network connection.  Neat.

Little talk on queueing theory.  Basic stuff from my simulation class back at UMich.  Yay for UMich teaching me something useful! Multi-queue vs. single-queue with multi-readers.  Single-queue rules if you can’t move folks between queues.  The metaphors being used are really getting stretching quite thin.  Quite quite thin.  Neat stuff on processing “groups” on one thread though.  Called a “conversation group” in service broker.  And you can associate some state with the conversation group to keep track of where you are in your conversation with the group.

It’s really nice to see Microsoft talking in such message-oriented ways.

So how does this all talk to other messaging systems?  I can’t believe I’ll want to do all my messaging inside SQL Server.  Ask the presenter and he indicated it can talk to outside messaging systems.  Interesting!

Anyway, back in.  Multi-reader queues.  They rule.  Great for scalability.

Some stuff about the transport.  Standard stuff.  Works over TCP/IP (multicast?).

The presenter uses OneNote and has an HP printer.  I can tell by what’s in the notification tray.  Heh.

Queues are built on top of tables.

Nice use of T-SQL to facilitate this.  It looks really easy.

Hmmm… Routes.  So you have to create Routes that tell Service Broker where to find named services.  So can services live on more than one machine?

Other stuff:  they can activate a stored proc based on a message showing up in a queue.  You basically map a stored proc onto a queue and when a message arrives for that queue, the stored proc is started up if it’s not started already.  They assume the stored proc will handle all of the messages on the queue.  Claim it’s better than triggers in other systems, as it doesn’t fire a trigger every time a message shows up.

Another push on database mirroring.  I’ll have to look into this one.  Might be handy.  It’s a failover plan, not a hot-hot plan.

Ooooo.. Parallel processesing with stored procs.  Apparently you can kick them off async now and glom results together later.  That could be very handy.  Also, async triggers that don’t slow down processing of the insert / update / delete that kicked off the trigger.  Not so great for RI, but could be interesting.

And that’s it.

Quotes:

“Not sure what exactly happened here, but I am hung.”

Often times, I have my own configuration files outside of the standard configuration framework (web.config / my.assembly.exe.config, etc).  When I’m developing a WinForm or Console app in VS.NET, I need to get a standard config file into the $(TargetDir) directory so my app will pick it up under testing.  VS.NET does this magic for you if you have an app.config file in the root of your project.  On build, it will be copied to $(TargetDir) and renamed appropriately.  Well, you can do the same thing with a PostBuild event.  Here’s a sample of one I use:

copy $(ProjectDir)MySuperSpecial.config $(TargetDir)MySuperSpecial.config

Very handy and it even works with the <solution/> task in NAnt!

I keep writing this class over and over.  It’s quite handy.

class ConsoleWriter : System.Diagnostics.TraceListener {
  public override void Write(string message) {
    Console.Write(message);
  }
  public override void WriteLine(string message) {
    Console.WriteLine(message);
  }
}