A couple of weeks ago, Paul Murphy pointed me at a SSB Wrapper Class that’s included in one of the SQL 2005 Beta 2 sample apps. That prompted an email from the SSB dev lead with a much better SSB library that they had written. You can get that library, along with two new samples that use it, up on the SQL Server Service Broker Developers Spot. The SSB Dev Spot is a community site dedicated to apps written on top of SSB. It’s run by Dan Sullivan of Developmentor, who is also hosting his new blog on the site. I hear Dan and fellow DM-ers Bob Beauchemin and Niels Berglund are all very excited about SSB. Nice to know I’m not the only one.

After seeing it on TSS.net, I checked out the X-develop product website. X-develop is a new multi-language cross-platform IDE that supports both .NET languages like VB.NET, C# and J# as well as Java. It includes support for all the .NET 2.0 features like generics as well as new Java 5.0 features like generics, varargs, enums and boxing.

When I checked out the website, I noticed a section covering “Custom Languages“. Here’s another example of bias against DSLs – this time in favor of “full grown OO languages”:

“The [X-develop] language plugin API is not limited to toy languages or little domain specific languages. Instead it supports full grown OO languages. In fact the support for Java, C#, J# and Visual Basic.NET is implemented as language plugins.” (Emphasis added)

This reminds me of the same kind of bias that was leveled against classic VB. Classic VB was valuable primarily because it was limited in scope and capability. But what it gave up in capability it gained in productivity. Along the same lines, DSLs are valuable because they are little, because they only focus on a single problem domain.

What exactly would be the value of another “full-grown OO language”? What features would be in a new full grown language that isn’t already in Java/J#, C# or VB.NET? The only feature I can think of is dynamic language support such as type inference and duck typing a la Ruby and Boo. What non-domain specific language features are you still waiting for?

Speaking of DSL Tools, Software Factories co-author Jack Greenfield just started blogging. He has jumped into the running debate between IBM’s Grady Booch and a variety of MS folks including Steve, Alan and myself. He does a good job summarizing the argument including pointing out where he and Booch agree:

In particular, we share the conviction that packaging knowledge for reuse in patterns, languages, frameworks, tools and other form factors is “the right next stage in cutting the Gordian knot of software”.

Jack rightly points out that while we all agree on these mechanisms for packaging knowledge that the devil is in the details. I look forward to seeing more on these details from Jack in the future.

Maybe it’s not as exciting as what my 2 year old has on tap for Xmas, but some of my Xmas came early when I got the new release of the DSL toolkit. The website isn’t updated yet, but the download is available.

This release is way beyond what the team shipped right after OOPSLA. For example, the code generation engine is in there now. So where you could only design the concepts of your modeling environment in the last release, now you can build a set of concepts in what is now called the Domain Model Designer, design a notation for that model using the Designer Definitions file (visual designer for this file to be a part of a future release) and build a set of code templates that can in turn generate code during the compilation process. Very cool.

I’ve only played with the updated walkthrus so far, but I’m pretty impressed. Major congrats to the team for getting this out. I saw Jochen in the cafe on Friday and discovered that the entire team has moved to building 25 which is right across the street from building 18 where my office is. Now I can go bother Jochen, Keith, Jack and the rest of the team without having to track all the way across campus! 😄

The simplest way to describe SQL Service Broker is “message queues in the database.” If the queues are tables in the database then you can do your entire message processing using a local transaction. If you use a separate queuing technology like MSMQ, you can still pull items off the queue, update data in the database and send out messages in the scope of a transaction – it just has to be a distributed transaction. Being able to use a local tx gives us a big performance gain. But, while important, this perf gain isn’t the most compelling reason to use SSB. It turns out that SSB provides important semantic messaging benefits in addition to perf benefits.

If you study at the semantic messaging model defined by message queuing systems such as MSMQ, MQ Series and WS-RM you’ll notice that it is inherently one way. Section 2 of the WS-RM spec defines the reliable messaging model to be between a source sending the messages and a destination receiving them. The problem with this model is that as message patterns between services gets richer, we’re going to want bi-directional reliable messaging. SSB calls this a dialog.

Before you can send messages between services in SSB (assuming everything’s been configured), you first have to BEGIN DIALOG and provide the initiating and target service, plus the message contract (more on that in a later post). Note that it’s called initiator and target, not sender and receiver. Either side of the dialog can send messages to the other as part of the contract by using SEND ON CONVERSATION – the only requirement is that the initiator sends the first message (hence the name “initiator”). All messages are guaranteed to be delivered exactly once and in order, or both sides of the conversation are notified of the failure and the dialog is torn down. I’m not sure if it guarantees in-order delivery of messages in opposite directions. There are cases where this might be important – I send an order cancellation as I send you a shipping notification – but typically there’s a business reason for who “wins” such a conflict. In this shipping/cancellation example, even if you sent me the cancellation before I sent shipment notification, it’s not like I can recall the shipment.

My only issue with this bi-directional reliable messaging is that I’m so used to thinking in terms of one-way RM that it’s taking me a while to wrap my head around it. Many of the sample interactions I come up with are simple patterns where the target simply acknowledges the incoming message. Order processing is a good example where I may get meaningful messages (i.e. not simple acks) coming from both ends. What are some others?