Morning Coffee 116

"Looks like I picked the wrong week to stop sniffing glue"
Steve McCroskey, Airplane!

• So it's been a while since my last post. Just over a month, not including The F5 High, which wasn't "original IP". Frankly, I just stopped reading pretty much cold turkey. I wanted and needed to go heads down on day job stuff for a while. Since I haven't been reading, Morning Coffee is going to be a little cold while I ramp back up.
• The new NHL season is upon us, and the Caps are looking good so far. Obviously, they have the new uniforms, but they're also out to a 2-0 start for the first time in five years. And in those two games, they've only allowed one goal and are 100% on the PK. It's nice to see them start strong, but obviously there's a long way to go. Here's hoping the can stay strong all season.
• Speaking of staying strong, the wheels that were rattling last week came off the Trojan bandwagon completely this week. I'm not sure it's as big an upset as Appalachian State beating Michigan but it's close. What happened to the team that scored 5 TD's in a row on Nebraska?
• Big news last week is that MSFT is going to release the source code to much of the .NET Framework. Scott Guthrie has the details. Frankly, between Rotor & Reflector, it wasn't like you couldn't see the source code anyway, so this seems like a no-brainer. But integrating it directly into the VS Debugging experience, that's frakking brilliant.
• I haven't had a chance to install the new XML Schema Designer (Aug 07 CTP)  but I was really impressed with this video. The XML Team blog has more details. However, I'm not sure what the ship vehicle is. The CTP install on top of VS08 beta 2, but in the video they keep saying "a future version" of VS, implying that it's not going to be in VS08.
• Dare is spending some time investigating SSB. I think it's interesting that some of the REST crowd are starting to see the need for durable messaging. Dare argues that the features and usage models are more important than wire protocol. As long as it's standardized, I don't care that much about the protocol. Several of the REST folks mentioned AMQP. While I've got nothing against AMQP technically (frankly, I haven't read the spec), but what does it say about durable messaging vendors (including MSFT) that a financial institution felt the need to drive an interoperable durable messaging specification?

Morning Coffee

• Libor Soucek continues our conversation about durable messaging. We still don't agree, but he says he "fine" with durable messaging. He does go out of his way to differentiate between *enterprise* and *supporting* systems. But when you're building connected systems, does that differentiation still matter?
• After taking a few months off, John deVadoss is back at the blog. Check out his Big SOA/Little SOA post. I especially like his snowball analogy "How do you build a big snowball? You start with a small snowball.") though he's also on this "middle out" bandwagon. Do we really believe "middle out" works, or are we just saying it because we know top down and bottom up don't? And John: You're welcome!
• Anyone coming to the Microsoft SOA & Business Process Conference this fall? Maybe we can have a shindig / blogger dinner / unconference / something?
• Remus Rusanu writes about SSB's dynamic routing. One of the (many) cool things about SSB is that all the addressing is logical, not physical. Routing is what binds logical addresses to physical addresses, and it's extensible.
• Martin Fowler discusses the value of sticking to one language. I agree with his points about large frameworks being as difficult to learn as a new language. I've said for a long time "If you build a framework, build tools to make it easy to use your framework". Language is obviously a core example of a tool. Another interesting point Martin makes is the traditional "intimate relationship" between scripting languages and C, but that the rise of JVM & CLR makes them impossible to ignore. Does the need to play well in a managed environment hinder a C based language like Ruby when compared to a natively managed scripting language like Powershell? Finally, Martin's "jigger of 80 proof ugliness" quote made me laugh.
• Politics 2.0 Watch: EJ Dionne says that DailyKos is doing for Democrats what Rush Limbaugh did for Republicans almost twenty years ago: mobilization. Josh Marshall points out that "what's happening today is vastly more participatory and distributed...than anything happening back then."

The Case for Durable Messaging in Service Orientation

Nick jumps on the durable messaging bandwagon, pointing out that it’s HUGE. Not just huge, or Huge but HUGE. But for my taste, he could emphasis it even more – HUGE – and still not capture just how important I think durable messaging is. But while he could use more bolding and italics, he certainly explains the problem well:

The reason that [reliability] becomes a problem in SOA is because the basic strength of SOA is the message, and the weakest link is the mechanism used to move the message. If we create a message but we cannot be certain that it gets delivered, then we have created a point of failure that is difficult to surpass.

Durable messaging solves two fundamental reliability issues:

1. Transactional Message Send. I want to send a message to some external service as part of a transaction. That is, I only want to send the message if the transaction commits. If the transaction aborts, I don’t want to send the message. The only way to do this is to durably record the intent to send the message within the transaction and then deliver the message after the transaction successfully commits.
2. External System Unavailable. I’m sending a message to an external service that is unavailable at the moment. Maybe it’s a temporary network condition, maybe it’s scheduled downtime, maybe the data center burned down, I don’t know. But because the message is durably stored, I can retry long after the sending transaction has committed. Furthermore, I can continue to retry (until success of course) even if my sending system reboots, fails over to a hot standby or has to be restored from backup (assuming you backed up after message was sent).

However, Nick points out that reliability has to be considered as part of our design, so do Agility, Flexibility, Scalability, Maintainability, etc. etc. etc. Agility and flexibility require standard transport protocols while scalability and maintainability require intermediation. Unfortunately, at this time there is no standard transport that provides intermediation and durability. Nick says that Microsoft’s “platform is lacking here”, but I’d say it’s an industry wide problem.

Nick mentions least three Microsoft technologies that provide some sort of durable messaging – MSMQ, SSB and BizTalk – but they’re all proprietary. The market leader in this space is MQ Series, which is also proprietary. WS-RM was supposed to be support durable messaging, but doesn’t. There is the Advanced Message Queuing Protocol group, which is defining an open protocol for MQ style systems, but without involvement from any major platform vendors I’m hard pressed to see this go anywhere. Personally, I’d love to see the SSB protocol published, and apparently the SSB wire protocol was designed “to be completely SQL Server agnostic.” Here’s hoping that happens.

Nick goes on to call WCF “immature” because of the lack support for message durability. I think that’s somewhat unfair: I think it’s WS-* that’s immature here, not WCF. It’s easy to confuse the two since they’re so joined at the hip in WCF v1. But WCF’s support for MSMQ shows that it can handle durable messaging, even though there is no usable standard for durable messaging in the WS-* stable. Over time, I think WCF will evolve to support a larger variety of messaging scenarios – WS-*, REST, durable messaging, etc. – out of the box. But for those of us who care deeply about durable messaging, WCF’s current lack of support is pretty frustrating.

Early Afternoon Coffee 81

These morning meetings are really cramping the "morning" style of these posts. But better late than never, I guess.

• Politics 2.0 Watch: Democrats pwn Republicans online. (via Balloon Juice)
• Roger Wolter writes about integrating SSB with WF, something I've experimented with myself. I didn't find the integration quite as natural as Roger did - transactions are a real PITA, and Roger apparently he hasn't looked into that yet - but I agree 100% with the idea that "most SSB programs end up looking a lot like a workflow." Looking forward to seeing your code, Roger.
• Pat explains his Newton vs. Einstein view of distributed systems and then rants about Consistency, Availability and Partition-tolerance. In particular, he discusses the evolution of what consistency (and to less extent availability) means in the face of loose coupling. Do yourself a favor and give up on distributed transactions now. Also, Pat points to another paper from CIDR dealing with isolation in services. Haven't read it yet, but I've added it to "the pile".  
• David Chappell writes about Service Component Architecture vs. Service Oriented Architecture. Since I don't "do" evangelism anymore, I don't spend much time watching what our competitors are doing. According to the SCA website, SCA is supposedly a "a model for building applications and systems using a Service-Oriented Architecture." But according to David, SCA 1.0 focuses on "portability, not interoperability, and so they don’t fully define the interactions between components necessary to create composites that cross vendor boundaries." I realize that we don't industry agreement on all the details of what SOA means, but I think we all agree that it's cross platform and cross vendor. Or maybe we can't even agree on that much.

Morning Coffee 70

• Scott Hanselman details how the "unblock" feature in Windows works. Basically, when you download a file with IE, it adds an alternate data stream that specifies the zone the file came from (Internet, Intranet, Trusted, etc.). Even more details on Bart de Smet's blog.
• Nick Carr gets off on a rant on Wikipedia, Citizedium and "the truth" that's pretty funny.
• Remus Rusanu shows how to to reuse SSB conversations in a data syndication scenario. A while back, he wrote about a lightweight pub/sub SSB implementation - barely 200 lines of T-SQL code - that would also be very useful in data syndication scenarios. I've got data syndication on the brain right now, so this stuff is very timely.

Morning Coffee 66

Yesterday's Morning Coffee was canceled on account of rain. In my living room. It's fixed now.

• Andre Vrignaud writes about MS Research's new High Capacity Color Barcodes technology. As he points out, there's some fascinating gaming potential for these barcodes because they have such high capacity (something like 2kb per square inch) and can be read without special equipment (a camera phone should work).
• According to a Pew Research Center report, Daily Show/Colbert Report viewers are significantly better informed than Fox News viewers. On the other hand, they're only slightly more informed than O'Reilly Factor viewers or Rush Limbaugh listeners so it seems like a wash.
• Speaking of The Daily Show and The Colbert Report, you can now download them from Xbox LIVE Video Marketplace. But at $2 160 points an episode, it's cheaper to set my DVR.
• I recently re-discovered Remus Rusanu's SSB blog. He went dark for a few months there, but he's recently posted a new version of his Service Listing Manager utility, presented SSB at DevConnections and showed how to implement a managed stored proc to receive SQL DDL event notifications. Event notifications is one of those features I didn't even realize was in SQL.
• Dottie Shaw, one of the program managers on my project, has started blogging. That leaves two team mates and one project member still not blogging.
• Yesterday, I stumbled into some other teams morale event. They were bogarting the cafeteria, so it wasn't like I was crashing it or anything. Normally, I wouldn't hang around some other teams party, but they had a projector, an Xbox 360 and two copies of Guitar Hero so I had to hang out and watch them play head-to-head for a while. That looks like a fun game.
• Chris Anderson writes at length about the primary enemy of Long Tail economics: "the absurdly complicated and expensive process of rights clearance". His case in point is the coming DVD release of WKRP in Cincinnati, which has replaced the dozens of songs used as background music with "Muzak-style songs that could be licensed in perpetuity for a small flat fee" that apparently "sucked ass".

Morning Coffee 58

• Nicholas Allen points out that Messaging is not a Transaction. Of course, what he really means is that Messaging with WCF is not a Transaction. Messaging with SSB is in fact a transaction (well, more accurately, it's transactional but you get the idea). Nick's right that you may not need anything more than simple retry semantics that you can implement yourself in your application protocol. But SSB has spoiled me. Why should I have to write the retry semantics? Why can't my messaging stack provide that for me? Or put another way, if I need a "precicely defined failure model", wouldn't I be better of choosing a messaging stack that provides that out of the box?
• Steve Hartman explains how to use span Remote Desktop Connection across multiple monitors for use with VPC. I wonder if this will work on my machine, since my multi-monitor setup is an L shape, not a rectangle. I'm offsite today, so I'll try it tomorrow (via DotNetKicks)
• According to news reports, Microsoft is negotiating to provide DRM free music too. I wonder how well this will work for Microsoft given that both Zune and PlaysForSure provide subscription services. I would assume the $15 all-you-can-listen style subscription services wouldn't be DRM free. Given that program is one of the (few) selling points they have over Apple, will the availablity of DRM Free music undercut the interest in subscription? (via Dale)

Answering Dr. Nick's Questions on SSB & WCF

Nick Allen asked on his blog about how people would like to see SSB and WCF work together. He's already heard these from me, but I figured I'd put them out there for everyone to see and debate. Plus, I had several beers last night at the MVP dinner, so this is likely to be more coherent than I was yesterday! :)

1. Are you interested in SSB because you'd like to have your service closer to the database? How close is close enough to the database?

I've first blogged about the endangered middle tier almost three years ago. My point at the time was that as you break your monolithic system up into services, the vast majority of those services won't need to scale out. You performance gets better the closer you are to the data. If you don't need to scale out, why not get the maximum boost by running in the database process itself?

Furthermore, in large IT shops, the database files are stored out on the SAN rather than on hard drives attached to the database server itself. That means the database server is effectively stateless. Why add a second stateless tier if you don't need scale out? If you need more performance in a given service, you can detach the database file from it's current SQL server box and attach it on another more beefy SQL server box without physically moving the database files at all. This enables what I call the "Star Trek Effect", where you can shift computing power where it is needed most (more power to the payroll system!).

Of course, if you're going to move the service, you do need to bring it down for a short time. That implies a need for durable messaging so that service consumers aren't affected by the brief service interruption. Which brings us to...

2. Are you interested in SSB because you need durable, duplex messaging between two services? Do you need exactly-once-in-order message delivery?

Yes. SSB has a bunch of other nice features, but durable duplex messaging is what I need the most. Exactly-once-in-order is also fairly critical, though there may be scenarios where it's not really necessary. Those are the exception, not the rule however.

Doesn't WS-RM already do EOIO already?

3. Are you interested in using SSB from WCF because you want a better asynchronous messaging experience than MSMQ? What makes you prefer SSB to other queuing products?

My primary problem with MSMQ for the problems I'm tasked with solving is that MSMQ is one way while SSB supports duplex messaging. You could do duplex messaging with MSMQ if you didn't mind managing multiple queues (one for each side of the conversation) but SSB does this for you for free. I'm sure there are scenarios where pure one-way messaging are useful, but they are few and far between in my day job.

Furthermore, SSB has the explicit idea of a service instance (they call it a conversation group) which MSMQ lacks. SSB's implementation is conceptually similar to the new WCF/WF integration work in the latest Orcas CTP.

Finally, SSB uses logical naming. You have conversations between services, but services get mapped to physical addresses at the routing layer. This allows services to move around more easily (see the "Star Trek Effect" in #1 above). Both MSMQ and WCF use physical addresses, which makes them much more difficult to move.

4. Are you interested in having your data contracts defined in WCF, SQL, or both?

I like WCF's data contract infrastructure. We did a early prototype long-running service with both WCF and SSB. the messaging stack code was obviously different, but we used the exact same data contract code. I even wrote some code to automatically deserialize the SSB message by mapping the SSB message type to a data contract.

I want my services to run inside the database, but that doesn't mean I want to write them in T-SQL. Personally, I'm much more productive in C# and/or WF. So WCF data contracts are fine by me.

Morning Coffee 45

• Yesterday's morning coffee was canceled on account of going to main campus and hanging out with the Architect MVPs. I spent all morning + dinner with them yesterday. Some of these guys I hadn't seen in nearly two years, so it was a ton of fun.
• Nicolas Allen (aka Dr. Nick) is looking for SQL Service Broker users. I cornered him at the MVP dinner last night and gave him my thoughts on WCF + SSB. You can head over to his blog and do the same. (I'll post my answers to his questions later today, hopefully)
• The new Vista x64 driver for my workstation's video card does support monior rotation, so I'm mostly XP free at this point. I'm dual-booting my workstation at this point, while I finish configuring stuff in the Vista partition. With both my workstation and work laptop tablet, I'm XP free at work. Next, I start getting home machines moved over.
• Tom Hollander reports on a new drop of the Guidance Automation Toolkit. Mostly bug fixes like Vista support, but the full list is here. It's an ugly upgrade process. You have to uninstall all existing guidance packages. I can't wait until this technology is "integrate[d] ... more deeply into Visual Studio and Team System".
• I mentioned the Podcast Authoring tool that I saw at TechFest last week. Here are some pictures of it from engadget (via Loke Uei Tan)
• I've been thinking of getting a Wii, and the fact I can hack code for it - managed code for managed snobs no less - is just another good reason to do it. (via DotNetKicks)

How I Learned to Stop Worrying and Love WCF

Regular readers of DevHawk are likely aware of my obsession interest in SQL Service Broker (aka SSB). I've also been doing a lot of WCF work lately. While there are parts of WCF that I think rock, overall I've found WCF lacking due to it's lack of support for long running services, which SSB excels at.

So it was with great interest that I read this recent article on Integrating WF and WCF. WF is expressly designed for long running systems, so I wanted to see how the article dealt with the WCF's lack of support for such scenarios. Unfortunately, the article basically sidesteps the issue. While it has lots of great info about hosting WF inside a WCF service, the article uses duplex channels for communication between the service and its clients. As I have pointed out before, this approach is impractical because it requires that both the service and its consumer remain alive in memory until the WF end.

Remember this quote from Essential WF?

"It is wishful thinking to assume that the operating system process (or CLR application domain) in which the program begins execution will survive for the required duration."

So basically this WCF/WF sample is wishful thinking. Fine for a demo, but given the severe lack of information out there on integrating these two technologies, I'm worried that many people will read this article as best practice guidance, which in my opinion would be a mistake.

But instead of firing up my blog (that is, like last time) to write a scathing post about how broken this sample is, I emailed Paul which led to a concall with Shy to discuss WCF's lack of support for long running services. Imagine my surprise when Shy agreed with me completely, furthermore saying that support for long running services had been "out of scope" for v1 of WCF. I thought that the whole point of duplex channels was for long running services. But apparently I was wrong.

Shy said to think of the duplex channel in terms of sockets, rather than long running conversations. And just like that, WCF made a ton more sense to me. I had been directly comparing the SSB and WCF communication models, but that's apples and oranges. It would be like comparing SSB to TCP.

If you think about it, vanilla HTTP works a lot more like UDP, even though it's layered on top of TCP. Both UDP and HTTP support connectionless operations and neither UDP nor HTTP are reliable or provide message ordering. The comparison isn't perfect: for example, UDP isn't limited to a single response for an incoming request. But by and large, HTTP is a very UDP style protocol.

If HTTP is basically UDP, then WS-* is trying to be TCP. Frankly, I never understood the point of WS-ReliableMessaging. I always thought reliability == durability == SSB or MSMQ. But when you realize that HTTP lacks TCP-like reliability and ordering capabilities, suddenly this WS spec makes sense. In fact, Shy made this exact point almost a year ago. At the time, I didn't get it because I didn't understand the duplex channel as sockets analogy. Now, I see the value of adding these capabilities to HTTP.

What Shy said was clear and to the point but unfortunately completely missing in the official WCF documentation. For example, the docs on Duplex Services say this:

A duplex service contract is a message exchange pattern in which both endpoints can send messages to the other independently. A duplex service, therefore, can send messages back to the client endpoint, providing event-like behavior. Duplex communication occurs when a client connects to a service and provides the service with a channel on which the service can send messages back to the client.

The docs make no mention that the "event-like behavior" of duplex services only works within a session. And I'm not the only one who mistakenly believed that duplex services could be used for long running services (here's an article in DDJ that makes the same mistake). Shy used the term "episodic" to describe services that span session boundaries. I'd like to see the docs updated to include that concept.

Taking the TCP/UDP analogy even further, I think it demonstrates how pointless the REST vs. SOAP debate is. As UDP is a thin layer on top of IP, REST is a thin layer on top of HTTP. But nobody argues much about UDP vs. TCP these days. I was in grade school when UDP and TCP were standardized, so maybe there were big TCP vs UDP flame wars at the time. But twenty five years later, it's pretty clear that TCP vs UDP is not an either-or proposition. Some protocols are better built on UDP while others are better built on TCP. I'm guessing we'll see a similar evolution with SOAP and REST.

Personally, I would expect that message exchanges between services will become more complex over time. Complex message exchanges would seem to favor stateful SOAP over stateless REST for the same reason complex network protocols favor connection-oriented TCP over connectionless UDP. But SOAP could never displace REST any more than TCP could ever displace UDP. Furthermore, as Larry O'Brien recently wrote "the onus is on the WS-* advocates to prove the need". TCP standardization only lagged a year behind UDP standardization where WS-* has lagged at least six years behind REST. I wonder if UDP would be more prevalent today if it had gotten a six year head start on TCP.

Finally, this "SOAP as Sockets" flash of understanding has also helped me understand how SSB / WCF can evolve together in the future. Some folks have suggested an SSB transport for WCF and I've personally looked into such an approach. But given since SSB is at a higher level of abstraction than WCF, it makes much more sense to layer SSB on top of WCF instead of the other way around. Today, SSB uses two protocol layers: the top level Dialog Protocol, which is built on top of the lower-level Adjacent Broker Protocol (ABP), which in turn is built on TCP. I'd like to see a version of ABP that was built on top of WCF instead of directly on top of TCP. SSB's Dialog Protocol would tie together the WCF duplex sessions into a long-running conversation the same way that it ties together TCP sessions today.

Eventually, I would love to see something that has the programming semantics of SSB and the interoperability of WCF. That would be like the the Reese's Peanut Butter Cup of service messaging.

Transactions in Workflow Foundation-land

I've been spending some quality time with SSB and WF of late. On the balance, my opinion of both these technologies is very positive, though each has some warts of note. For Service Broker, they got the transactional messaging semantics right, but much of the lower level connection management - what SSB calls "routes" are clumsy to deal with. For Workflow Foundation, the execution model is amazingly flexible. Unfortunately, WF's support for transactions is significantly more rigid.

If you're build a SSB app, you're typical execution thread looks like this:

1. Start a transaction.
2. Receive message(s) from top of the queue.
3. Execute service business logic. Obviously, this varies from service to service but it typically involves reading and writing data in the database as well as sending messages to other services.
4. Commit the transaction

When I sat down to marry SSB and WF, I naively assumed I could simply use WF for step three above. Alas, that turns out to be impossible. This thread on MSDN Forums has most of the gory details, but the short version is that WF does not support flowing host managed transactions into the workflow instance. As per Joel West in the aforementioned thread:

"[T]he WF runtime in V1 only supports flowing in a transaction on WorkflowInstance.Unload. There are various ways that you could try and hack this (with a custom persistence service or WorkflowCommitWorkBatchService) but if you do this it won't work correctly 100% of the time and the times when it fails (error conditions or failures causing the tx to rollback) will be exactly when you are expecting transactional consistency.

Bottom line - the only way to make this work is to call WorkflowInstance.Unload inside your transaction scope.  This was the best that we could do in V1 to try and enable this pattern in some form.  Not always ideal but it can be made to work for most scenarios that require usage of an external transaction."

So the WF compatible execution thread looks like this:

1. Start a transaction
2. Receive message(s) from the top of the queue
3. Load/Create the associated workflow instance for the received messages
   • All messages received are guaranteed to be from the same SSB conversation group, which is roughly analogous to a WF instance, so this turns out to be fairly easy
4. Enqueue the received message in the workflow instance
5. Unload the workflow instance
6. Commit the host transaction
7. Reload the workflow instance
8. Run the workflow instance (note, I'm using the manual scheduling service)
   • Workflow instance creates a transaction if needed
9. Unload the workflow instance (typically done via UnloadOnIdle in the persistence service)
• Assuming the workflow instance needed a transaction, it gets committed after unload

Basically, you use two transactions. One host managed transaction to move the message from SSB to WF instance and one WF managed transaction to process the message.The need for two transaction instead of one is unfortunate, but required given the current design of WF. And frankly, given the importance and difficulty of transaction management, I'm not that surprised that WF has hard coded transaction semantics. Trying to build a generic transaction flow model that would work in the myriad of scenarios WF is targeting would have been extremely difficult. At least there is a work around, even if it means using two transactions and loading and unloading the workflow instance twice.

However, there is a silver lining to the two transaction approach: two unexpected benefits when dealing with poison messages. First, SSB doesn't have dead letter queue like MSMQ does. Moving a poison message to a dead letter queue would break SSB's exactly once and in order semantics.(MSMQ doesn't guarantee in order delivery) But moving all messages into the WF instance gets them out of the main SSB queue so poison messages don't continue to get processed over and over.

Second, because the workflow instance is peristed after the messages are enqueued, there's a representation of the workflow after the message is received but before the message is processed. If there's a poison message, attempting to processing the message will fail and rollback to this state. This persisted workflow instance could be sent to a developer who could step through it to determine the cause of the error. We could even have developer versions of runtime workflow services so we could read remote data and simulate data updates. I wouldn't want the developer updating production data in this way, but it would be great for troubleshooting issues.

Slight Workflow Annoyance

One of the cool things about WF is that you can specify the Guid it uses to identify a workflow instance. WorkflowRuntime.CreateWorkflow has an overload (actually two) where you can specify said workflow instance identifier. This is awesome for using WF with Service Broker, as Service Broker already has the idea of a conversation group which is roughly analogous to a workflow instance. Conversation groups even use a Guid identifier, so there's not even any mapping required to go from conversation group to workflow instance.

However, things get less cool when you call WorkflowRuntime.GetWorkflow. If you call GetWorkflow with a Guid that has no corresponding workflow instance, it throws an InvalidOperationException instead of just returning null. That seems like an odd choice. If you're going to support specifying the instance identifier when you create the workflow instance, doesn't it make sense that you should also gracefully support the scenario where an instance identifier is invalid?

I see two ways to deal with this:

• Iterate through the list of loaded and persisted workflow instances looking for the one in question.
• Call GetWorkflow and swallow the exception.

I ended up picking the "Swallow the Exception" approach as I can't imagine the iteration thru every loaded and persisted instance would be very performant. But swallowing exceptions always makes me feel icky. I'm a fan of the "exceptions only for exceptional situations" approach and as far as I'm concerned, an invalid instance identifier isn't that exceptional. Still, it's a minor annoyance, especially given how cool it is to be able to specify the workflow instance identifier in the first place.

The Two Types of Service Architects

Tomas Restrepo comments on my recent SSB and WCF posts:

Harry Pierson asks how well WCF supports long running tasks. He suggests that WCF does not support them very well, and says that's one reason he likes SQL Server Service Broker so much. I'd say SSSB is a good match only as long as the long running tasks you're going to be executing are purely database driven and can be executed completely within the database. Sure, this is an "expanded universe" with the CLR support in SQL Server 2005, but even so it makes me nervous at times .

You could also consider using a custom service with MSMQ or something like BizTalk Server for this if you had long running processes that were not completely tied to the DB (or a single DB for that matter).

Sam Gentile follows up:

In that same post, but I needed to call it out separate, Tomas rightfully says, "I'd say SSSB is a good match only as long as the long running tasks you're going to be executing are purely database driven and can be executed completely within the database," in response to Harry liking Service Broker so much. Talk about a narrow edge case. That's way I never really got excited or cared about Service Broker. Its a narrow solution to a special edge case when everything is database driven and can be executed totally inside the database. That's the old Microsoft Data-Driven Architecture for sure. Me, I'd rather have a rich Domain-Driven architecture most of the time. Then if you have Oracle databases in your architecture too, where does it leave you? Nowhere.

As you might expect, I have a few comments,  clarifications and corrections.

First, Tomas' statement that Service Broker only supports service logic "executed completely within the database" in flat out wrong. Service Broker can be used from any environment that can connect to SQL Server and execute DML statements. If you can call SELECT/INSERT/UPDATE/DELETE, then you can also call BEGIN DIALOG/SEND/RECEIVE/END CONVERSATION. This includes Windows apps and services, web apps and services, console apps and even Java apps. Of course, you can also access Service Broker from stored procedures if you wish, but you're not limited to them as Tomas suggested.

Tomas' misconception may come from a feature of Service Broker called Activation. Activation is a feature of Service Broker that dynamically scales message processing to match demand. For example, Service Broker can be configured to launch a new instance of a specified stored procedure if messaging processing isn't keeping up with incoming message traffic on a given queue. This is called internal activation and because it uses stored procedures it does execute within the database as Thomas said. Service Broker also supports external activation where it notifies an external application when activation is needed. You do have to build an application to host your service logic and handle these notifications, but that application doesn't execute within the database. So while you could argue that it's easier to execute your service logic within the database (no need to build a separate host app), it's not required.

Given that you don't have host your service logic in the database, then you're also not limited to "a single DB" as Tomas suggests. You don't, in fact, have to put your Service Broker queues in the same database with your business data. So if you have Oracle in your environment, like the scenario Sam mentioned, you would host your service logic in an external application that processed messages from a queue in a SQL 2005 database while accessing and modifying business data from tables in the Oracle database. Using multiple databases does require using distributed instead of local transactions, but if you're using MSMQ as Tomas recommended, you're already stuck with the DTC anyway.

Finally, I didn't get Tomas' "purely database driven" or Sam's "everything is database driven" comments at all. While there are exceptions, the vast majority of systems I've ever seen/built/designed have essentially been one or more stateless tiers sitting in front of a stateful database. If it's a traditional three tier web app, there's a stateless presentation tier, a stateless business logic tier and a stateless data access logic tier. For a web service, there's no presentation tier, but there's is the stateless SOAP processing tier typically provided by the web service stack. Does this mean the vast majority of web apps and services are  "purely database driven" too? If so, then I guess it's a good thing, right?

In the end, maybe there are two types of service architects - those that believe the majority of services will be atomic and those that believe the majority of services will be long running. For atomic services, Service Broker is overkill. But if it turns out that most services are long running, WCF's lack of support is going to be a pretty big roadblock.

I'm obviously in the long running camp. I'm not sure, but I get the feeling this is the less popular camp, at least for now. We'll have to wait to see, but I do know is that whenever someone brings me what they think is an atomic business scenario, it doesn't take much digging to reveal that the atomic scenario is actually a single step of a long running business scenario that also needs to be automated.

Here's a question for Tomas, Sam and the rest of you: Which group do you self select into? Are most services going to be atomic or long running in the (pardon the pun) long run?

The Other Foundation Technology

I mentioned last week that WF "is one of two foundation technologies that my project absolutely depends on". Sam Gentile assumes the other foundation technology is WCF. It's not.

As a quick reminder, my day job these days is to architect and deliver shared service-oriented infrastructure for Microsoft's IT division. These services will be automating long running business operations. And when I say long running, I mean days, weeks or longer. While there will surely be some atomic or stateless services, I expect most of the services we build will be long running. Thus, the infrastructure I'm responsible for has to enable and support long running services.

The other foundation technology my project depends on is Service Broker. Service Broker was expressly designed for building these types of long running services. It supports several capabilities that I consider absolutely critical for long running services:

• Service Initiated Interaction. Polling for changes is inefficient. Long running operations need support for the Solicit-Response and/or Notification message exchange patterns.
• Durable Messaging. The first fallacy of distributed computing is that the network is reliable. If you need to be 100% sure the message gets delivered, you have to write it to disk on both sides.
• Service Instance Dehydration. It's both dangerous and inefficient to keep an instance of a long running service in memory when it's idle. In order to maximize integrity (i.e. service instances survive a system crash) as well as resource utilization (i.e. we're not wasting memory/CPU/etc on idle service instances), service instances must be dehydrated to disk.

In addition to these capabilities, Service Broker supports something called Conversation Group Locking, which turns out to be important when building highly scalable long running services. Furthermore, my understanding is that Conversation Group Locking is a feature unique to Service Broker, not only across Microsoft's products but across the industry. Basically, it means that inbound messages for a specific long running service instance are locked so they can't be processed on more than one thread at a time.

Here's an example: let's say I'm processing a Cancel Order message for a specific order when the Ready to Ship message arrives for that order arrives. With Conversation Group Locking, the Ready to Ship message stays locked in the queue until the Cancel Order message transaction is complete, regardless of the number of service threads there are. Without Conversation Group Locking, the Ready to Ship message might get processed by another service thread at the same time the Cancel Order message is being processed. The customer might get notified that the cancellation succeeded while the shipping service gets notified to ship the product. Oops.

There's also an almost-natural fit between Service Broker and Windows Workflow. For example, a Service Broker Conversation Group and a WorkflowInstance are roughly analogous. They even both use a Guid for identification, making mapping between Conversation Group and WF Instance simple and direct. I was able to get prototype Service Broker / WF integration up and running in about a day. I'll post more on that integration later this week.

Last but not least, Service Broker is wicked fast. Unfortunately, I don't have any public benchmarks to point to, but the Service Broker team told me about a private customer benchmark that handled almost 9,000 messages per second! One of the reasons Service Broker is so fast is because it's integrated into SQL Server 2005, which is is pretty fast in it's own right. Since Service Broker is baked right in, you can do all your messaging work and your data manipulation within the scope of a local transaction.

Service Broker has a few rough areas and it lacks a supported managed api (though there is a sample managed api available). Probably the biggest issue is that Service Broker has almost no interop story. If you need to interop with a Service Broker service, you can use SQL Server's native Web Service support. or the BizTalk adapter for Service Broker from AdapterWORX. However, I'm not sure how many of Service Broker's native capabilities are exposed if you use these interop mechanisms. You would probably have to write a bunch of application code to make these capabilities work in an interop scenario.

Still, I feel Service Broker's unique set of capabilities, its natural fit with WF and its high performance make it the best choice for building my project's long running services. Is it the best choice for your project? I have no idea. One of the benefits of working for MSIT is that I get to focus on solving a specific problem and not on solving general problems. I would say that if you're doing exclusively atomic or stateless services, Service Broker is probably overkill. If you're doing any long running services at all, I would at least give Service Broker a serious look.