• Akira in HD from XBL Video Marketplace?
  
  Coolness.
• Omar Shahine has the WL Hotmail + Outlook scoop. Download it here. I’ve used this product off and on over the past few years. Typically, I would use it, love it, but then never get around to reinstalling it after a repave since it was subscription-only product.
• Microsoft releases eScrum project management tool. I’ve seen this internally but haven’t used it yet. However, I have no doubt that the cool kids will deem it “not hot” in favor of Mingle. (via Larkware)
• Ted Neward writes at length about relational databases, object databases and OR mapping. Ted may be Switzerland when it comes to platform, but he has no problem taking sides and mixing it up when it comes to data & object persistence. He makes some interesting points that mostly boil down to “different tools for different jobs”. Also, has the dual schema problem entered the general vernacular, or just Ted’s?
• Nick Malik survives his trip to Nashville and has some thoughts on Ruby, Microsoft and alpha geeks. His point about the alpha geek track record (he sites Powerbuilder, Delphi and EJB) is spot on. This is something I’ve been thinking about since ETech last year. How good are alpha geeks at trendspotting? For every technology they adopt that makes the mainstream, how many don’t? I’m guessing quite a few more than the three Nick mentions.
• Speaking of alpha geeks, this whole ALT.NET silliness reminds me of the famous Groucho Marx quote: “I don’t want to belong to any club that will accept me as a member.” Though maybe I’m just bitter because “Working at MS” has been deemed “not hot”. 😄

• The eBay Architecture SD Forum presentation that spawned the whole Transactionless meme is available here. As I reported yesterday, it doesn’t call for going completely transactionless as Martin suggested. It calls for going without distributed transactions, which I agree with 100%.
• More interesting than the transactional aspects, I found the data tier functional segmentation information facinating. Too bad those guys aren’t using our platform, SSB was expressly designed for exactly this sort of segmentation. I also liked that step 1 for “massively scaling J2EE” is to “throw out most of J2EE”.
• After going mostly dark since last august, the manager of my old team John deVadoss has been blogging up a storm since the beginning of March. So has my old boss Mike Platt. I wonder what happened at the begining of March? Here’s hoping this blogging fever spreads on my old team.
• Joe McKendrick: “The bottom line is that ROI on SOA is an enterprise challenge, not an IT challenge.” Truer words are rarely spoken.
• The rumor mill on the Black Xbox 360 “Elite” are coming fast and furious. I don’t care about the HDMI port (my HDTV is five years old and doesn’t have one) but I would like a bigger hard drive…

Honestly, this post started off as a rant entitled “Is it Me, or is DB Development a Pain in the Ass?” about the sorry state of database development tools in Visual Studio. But in searching around on MSDN for information about the built-in “Database Project” type (which could more accurately be called “just a bunch of SQL scripts”), I stumbled across information about the Database Professionals edition of Visual Studio Team System. That’s right, I had forgotten that we shipped this late last year.

I short, VSTDB (or whatever the “official” acronym is) is 90% of what I was looking for in a DB dev tool. Sure, it’s not perfect, but it’s a massive improvement over the previous state of the art.

The primary feature of VSTDB is the ability to “build” your database the same way you build your code. You use lots of small scripts that get compiled together into a model (for lack of a better term) of the database as you’ve defined it. That model can be deployed to a new database instance or used to update an existing instance. You can also compare that model against an existing database in order to determine what’s changed and automatically build update SQL scripts for the DBA’s to run in the production environment (since you don’t want your developers doing that).

It takes a little getting used to, but the “lots of small scripts” approach has a lot of upside. If you have a table with a primary key, you’re supposed to define the primary key, indexes, constraints, triggers, etc. in separate scripts from table creation script. This makes things much easier when you’re trying to figure out what’s changed in your source control system.

VSTDB has a variety of other cool looking features like data generation and unit testing, but I haven’t really dug into them much yet. One thing that VSTDB supports that I wasn’t expecting was Service Broker! SQL Management Studio has limited SSB support – if you want to create new SSB objects you have to write the DDL directly. VSTDB requires you to write the SSB DDL also (it makes you write DDL for everything, see below) but it at least has templates for all the SSB object types. Very Cool!

Of course, there are always things that could be improved. The T-SQL editor does syntax highlighting but not IntelliSense. It doesn’t support the existing visual database tools like the Table Designer. And while you can build T-SQL stored procs, functions, types, etc, VSTDB doesn’t support the development of managed SQLCLR stored procs, et.al. Things to work on for v2, I suppose.

If you’re using VS Team Suite, you can download an add-on that adds VSTDB functionality to your existing VSTS installation. It’s only 8MB, so it’s definitely the way to go for Team Suite users.

I’ve been having a conversation with Piyush Pant over on his blog that started as a comment he left on my Services Aren’t Stateless post. He thinks that I’m “missing the crucial point here by implicitly conflating business process and service state”. While Piyush hasn’t really defined what he means by these terms, I think I understand what he’s getting at. Yes, process and service state are different in many ways, but they are also similar in that they are both service private data.

Pat Helland (side note – I wish Pat would start blogging again) wrote an article some time ago titled Data on the Outside vs. Data on the Inside where he talked about the differences between service private data and data in the space between the services. For example, data on the outside is immutable, requires an open schema for interop, doesn’t need encapsulation and is representable in XML. Service private data is not immutable, doesn’t need an open schema for interop, requires encapsulation and is typically stored in a SQL RDBMS. So on this front, process and service state are both service private data so conflating them makes some sense.

However, what’s not in the article is the idea of Resource and Activity data. Not sure why Pat didn’t include this in the article, but he was talking about it as far back as PDC 2003. Stu Charlton described the difference between resource and activity data in his Autonomous Services article:

Activity Data – This is “work in progress” data for any long-running business operation, and is usually encapsulated by business logic. A classic example is a shopping cart in any e-commerce system. This data is mutable, but typically has low concurrency conflicts, as it is not widely shared. Typically activity data retires after a long running operation completes, and may be archived in a decision support system for later analysis.

Resource Data – This is “state of the business” data, which represents the resources of an organization, and is usually encapsulated by business logic. Examples are: room availability in a hotel, inventory levels in a warehouse, account statuses, employee and customer information. Some resources have a small life span, others may last a very long time (years). Resource data is usually volatile with potential for high concurrency conflicts.

So I’m fairly sure that when Piyush says “process state” I should hear “activity data”. Similarly “service state” is “resource data”. The differences between activity and resource data lead to some interesting implementation artifacts, which I assume he getting at when he says I’m conflating the two. For example, since activity data like shopping cart has low or no concurrency issues, using an optimistic concurrency scheme is entirely appropriate, which you would never use for highly volatile resource data like warehouse inventory levels. In fact, since activity data doesn’t have concurrency issues, you could even store it inside an instance of workflow or orchestration, which gets serialized to a persistent store when it’s in an idle state.

However, the fact that activity and resource data is handled differently doesn’t mean that most services won’t have activity data. When Thomas Erl says that that stateless services is a “common principle of service orientation”, essentially what I think he’s saying that services should only have resource data. And as I said before, this seems wrong to me. Sure, some services will be stateless. But all services? Services implement business capabilities. Most business capabilities are long running processes. Doesn’t that imply that most services in the enterprise will need to be long running workflows or orchestrations?

So for the most part, Piyush and I just seem to have different names for the same concepts. The one issue I have with Piyush’s descricription of process and service state is that he seems to implicitly assume that processes aren’t services. Why not? Again, not all services will be processes, but if you’re not exposing processes as services, how exactly are you exposing them?

My pal Tim dropped me an email last week to let me know they (the ADO.NET team) were publishing their vNext vision around entities. Of course, they picked the week when I’m in San Diego! So I didn’t get a chance to look at it until today. In a nutshell, they are raising the level of abstraction for databases. Regular DevHawk readers know I talk about abstraction a lot around here. In fact, one of my earliest posts on this blog – 1 house, 2 kids and 5 jobs ago – was on Disruptive Programming Language Technologies. So this is a topic near and dear to my heart.

This is an amazingly good thing. Think of the impact VB had on the development industry, but bigger. The abstraction level of databases hasn’t been raised in decades. It’s about freaking time we did.

My only problem with the article is that it’s pretty obtuse. Referring to this as “Making the Conceptual Level Real” makes it sound much less exciting than it really is. Nobody refers to C# as a “conceptual” programming language. But if you use the terminology from the vision article, that’s exactly what it is. Machine code is the physical level, IL is the logical layer and C# would then be the conceptual layer. But lets say you build a compiler that compiles C# directly to machine code. Would it suddenly become the logical layer? Who knows? Who cares? Let’s just raise the level of abstraction and not get all caught up naming the level we’re currently at.

VB was introduced 15 years ago in 1991. Most developers in the industry are aware and remember the impact VB had (if you don’t, check out Billy Hollis‘ History of BASIC). The relational model was introduced 36 years ago, The first RDBMS was introduced in 28 years ago. I’d bet the majority of developers in the industry today don’t remember a time before databases. Hell, I was introduced 36 years old myself. (I’m sure my dad remembers programming before databases, but he doesn’t code much these days.)

As I said, this is going to be big and it’s about freaking time. So hats off to the ADO.NET team. Can’t wait to see this running. According to this, first CTP drop is August, so you don’t even have to wait too long.