Conceptually, I like both Service Oriented Architecture (aka SOA) and Software as a Service (aka SaaS). However, I think we’ve done the industry a disservice by overloading the term “service”.

John deVadoss likes the following definition of SaaS from Wikipedia. So do I.

Software as a service (SaaS) is a model of software delivery where the software company provides maintenance, daily technical operation, and support for the software provided to their client. SaaS is a model of software delivery rather than a market segment; it assumes the software is delivered over the Internet. Software can be delivered using this method to any market segment including home consumers, small business, medium and large business.

To paraphrase, SaaS is software that traditionally you might have bought, installed and run yourself but instead now can access over the network where someone else is responsible for installing and running it. For example, instead of buying, setting up and managing my own mail server to handle a single @devhawk.net email address, I use the WL Custom Domains service.

SOA on the other hand isn’t a model of software delivery, it’s a model of software segmentation. Again, here’s the Wikipedia definition, this time for SOA:

There is no widely-agreed upon definition of Service-oriented architecture other than its literal translation that it is an architecture that relies on service-orientation as its fundamental design principle.

Err, that’s not very helpful. Let’s check out the OASIS definition (cribbed from Wikipedia).

[SOA is] A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Well, at least it’s not a self-referential recursive definition. But it is littered with committee-speak. (Who talks like that in real life?) Frak it, here’s my definition:

SOA is a way of implementing IT systems as a web of interconnected yet independent loosely coupled subsystems (typically called services) instead of as big honking systems we have traditionally built that tend to be unwieldy, in-agile, difficult to change and probably obsolete by the time they were deployed.

We could argue about the language, but you get the point. There would be a ton of argument about the size of the subsystems (i.e. the service granularity), but I think most people can agree that SOA encourages building multiple smaller interconnected subsystems instead of one big (honking) system.

Which brings me back to my original point: Service, in the SOA sense, describes the approach to factoring parts of an software solution. Service, in the SaaS sense, describes a software delivery mechanism. Certainly, you can use both together and take an SOA approach to building a SaaS product. But you don’t have to. So having the same term “service” used in both is very confusing.

How many SaaS products use SOA today? I would guess “not many” since there hasn’t been much demand for it. When you’re selling to the long tail of the LOB market, support for service-oriented integration isn’t a critical selling feature. As SaaS becomes more attractive to larger companies (i.e. ones with dedicated IT staffs), using a SOA approach will be more important to SaaS product vendors. So they will converge in a way, but not in the way their naming suggests.

Of the two uses, SaaS seems closer to the dictionary definition of service. Maybe the S in SOA should stand for “Subsystem”? Nah, I like the term “connected systems” better than “service oriented” anyway.

• 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…

• John Backus, leader of the team that developed the first high-level programming language, died yesterday. It’s been a hard year so far for IT industry luminaries. (via Good Math, Bad Math)
• Yesterday, I followed on Martin Fowler’s post on going transactionless. As I said yesterday, I didn’t agree with the idea of no transactions inside a service, but I agree 100% with no transactions between services. Via Paul Brown, we learn that EBay does allow forbids the use of client-side or distributed transactions, but doesn’t outlaw the use of transactions in general. That makes much more sense to me since transactions between services would have to be are distributed.
• Wired just launched a new blog called GeekDad with the mission statement “Cool toys and fun projects you and your kids do together”. Subscribed (via The Long Tail)
• DevHawk made Todd Bishop’s Microsoft Blog Directory. It’s in the “Software Development and Design” section. Not sure why I’m listed above Raymond Chen, John Montgomery, Chris Sells and Don Box in that section, but that’s nice company to be included with.

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.

• USC is in the Sweet 16. Not sure when that’s ever happened before.
• Politics 2.0 Watch: The rise of political blogs in main stream media reporting. Check out what the LA Times has to say about Talking Points Memo. 2008 is going to be interesting and ugly.
• Jeffrey Palermo wrote that Scott Guthrie showed him a prototype web MVC framework for ASP.NET. Looking forward to seeing that. I thought it was interesting that Jeff described web MVC as “like Rails and MonoRail”. Didn’t Web MVC initially gain popularity on Java with toolkits like Struts and Spring? (via Larkware News)
• For reasons that can’t be explained, I haven’t read Eric.Weblog() in quite a while. My loss. His post on Boundaries was both thought provoking and hilarious, a hard combo to achieve in practice.
• New versions of Expression Design (Beta 2) and Expression Blend (Release Candidate) are available.
• Martin Fowler writes about being Transactionless. I like to see people thinking this way, because I don’t believe transactions across services is feasible or loosely coupled. However, I still think you should use transactions inside the service. Also, I gotta wonder how much time all that error checking logic you have to write takes if you’re not using transactions. What’s the tradeoff?