Do you consider your database as a service? It's worthwhile to review the tenents of a service oriented architecture. The first two tenents above are probably the most relevant to my question.

If you do all of your data access through stored procedures, then you might say your database boundary is explicit.

If your database doesn't depend on other services or applications to exist properly, then you could say that your database is autonomous. That's a little tricky. Although we may use stored procedures to access functionality in our database, we may have well known practices that we have to call the ap_decrease_inventory proc after we call the ap_ship_order proc to make sure our that our database values are all in check. I wouldn't call our database autonomous if it has to rely on these external rules being inforced.

I'm going to avoid the discussion of the last two tenents because I think the are a bit to pure for my question. I'm really just trying to differentiate between two types of databases that I see out there. For my purposes, I refer to these as Databases as Services, and Databases as File Systems.

Databases as Services typically are well encapsulated and contain business rules. These databases might be supporting several client applications. You probably take great care in these databases, designing them carefully, perhaps with modeling tools, and encapsulating the persistence function with stored procedures, functions, triggers, etc. You may or may not have a well defined data access layer in your client applications. You might consider all the stored procs to be your data access layer, so you might call you procs directly from UI and/or business layers of your application, but that really depends on how well your client application is written. From you database, you don't really care so much since it's well protected service that operates autonomously.

Databases as File Systems are much less strategic. They serve one purpose only - to save stuff from your application. You probably/hopefully have a well defined data access layer in your application. That may even be an Object Relational Mapping tool (ORM). You probably designed the database to support the persistence of the objects in your application, and to generalize, you probably only have one application using this database. The most important thing though is that all of your business rules should be in your application(s). This type of database doesn't mean you don't have db side logic such as stored procedures or triggers. You may decide for optimization reasons that some code needs to live closer to the tables and that's okay. It's okay, so long as you realize it's harder to reuse some of that logic in higher layers of your application and you are comfortable in having your logic live in multiple platforms.

Stored Procedures are increasingly being used to add encapsulation to our database. No longer is performance the rationale for stored procedures. And increasingly, we are seeing advanced services in our databases - 4GL code such as Java and .NET managed code are making their ways into our databases. User Defined Types, Objects, and with the next version of SQL Server, we're seeing a full fledged message queue mechanism with Service Broker. You can even host web services directly in SQL Server 2005.

Is your database a service? Which camp do you fall into? Unfortunately, I think many people live somewhere in between, and that isn't by design. Most of the architectural decisions here should be motivated by where you decide to draw your boundary for strategic reasons, not for what is handy at the moment. I'd like to see people more consciously make this decision and remain committed to it. What are your thoughts?

This past 3 days I've spent traveling to and from Redmond to visit with a few of the developer tools teams as part of an Software Design Review (SDR). These are a kind of focus group, with the intention of getting qualitative information from folks about what they'd like to see in upcoming development tools. Hopefully I'll be able to talk more about the content after PDC in the fall so stay tuned. It was a refreshing trip in that normally, I'm traveling to either learn or teach. During this trip I was there more to discuss and influence and I got a real sense of just how careful Microsoft listens to the community.

It's fitting that I drove down to Redmond from Vancouver, passing through the town of Everett and past the Whidbey and Orcas islands (part of the San Juan Islands). These names are probably familiar to some of you as code names for Visual Studio 2003 (Everett), 2005 (Whidbey) and beyond (Orcas). For the sake of completeness we should add Rainier as well which was the code name for Visual Studio 2002. Geographically, these go from south east to north west passing more or less through Redmond.

Not unlike the development of these versions, the journey between these stops is a windy road, taking you over hill and vale, and over several bodies of water. What's after Orcas? Well the next leg of the journey is as ambitious as the following version after Orcas, namely Hawaii. If you look at this path on a map, you'll see that this is indeed quite a leap.

The most interesting thing that happened is that I realized that come Orcas, I'm likely only going to be interested in coding in Visual Basic, and not C#.

I've had this question in many of the VSTS bootcamps I'm teaching across canada. “From my Application Diagram, how do I create a deployment diagram that shows my web application and database being deployed on the same box“.

So I posed the question to my friend and fellow RD Joel Semeniuk. The answer is:

with the LDD you CAN NOT represent a web site and a database server on the same logical server.

The Logical Datacenter Designer is used to create diagrams of interconnected logical servers that represent the logical structure of a datacenter. They key here is the term “logical server.

My understanding (hope) was different. My understanding of the term “Logical“ was that in the datacenter diagram, a logical server was a “type“ of server, not a physical instance of a named machine. But if this is the way the LDD is going to work, then it's useless and I guess what we really need is a Physical Datacenter Designer. To be honest, I don't think we need a LDD, just a DD that works correctly. Otherwise, how the hell can you create a deployment diagram out of something that doesn't represent real machines - or at least a type of machine?

If the LDD is going to continue to work this way, then the deployment diagram (and even the LDD) start to look just like your Application Diagram. Furthermore, if a Logical Server is intended to be (possibly) aggregated with another Logical server to become a physical server, then why would you ever be allowed to put them in different zones. There is some serious impedence going on here. I seriously hope this gets fixed/repositioned before RTM. It would be sad to come this close to getting it right on a great suite of modelling tools.

I'm just heading back home from Vancouver tonight on a red eye. When I get home, I have time for a load of laundry or two and then I'm flying to Mexico. Not just for some R&R, but I've also arranged to speak at the Mayan Riviera .NET User Group. (MR. Nug). I'm not sure what is better - going on vacation, or being able to write it off as a business expense. Unfortunately the only Spanish I know is “Dos cervasa por favor“ therefore this talk will be in English. My apologies.

I'm going to be speaking about the new DataSet that is coming in Whidbey. By the time I get there, beta 2 should be available for download and it should be public knowledge that ObjectSpaces will finally be shipping as part of the whidbey release. I just got a preliminary build last night, so I'm going to try to do a demo of using a dataset with O/R mapping via ObjectSpaces.

As you may have also heard, bundled into 2.0 Typed Datasets are Typed DataAdapters, also known as TableAdapters. In addition to TableAdapters, beta 2 will introduce typed forms, known as TypedForms. These will be precanned forms for both Web and Windows access that couples an easily painted form right on top of a dataset...with zero code. The cool thing about this is that you can simply add a column to your database table, and this will automatically change your data access layer, your middle tier entity and data entry forms. Likewise, you'll be able to simply drag a text box onto your TypedForms and this will automatically modify your database schema to add a new column to the table.

There is also some discussion going on about also adding a TypedReport into the dataset that couples Sql Reporting Services Reports directly into your typed dataset class. This stuff is going to be so easy to use, that it is likely going to make it's way into InfoPath as part of the Office product so that end users can create their own data entry forms and reports in InfoPath. This new edition of InfoPath is going to be named “InfoMaker“. More information on this is available here. This new collection of classes in the dataset are now going to be collectively known as a "DataWindow". Again, more details here. No, it's not a snowy day hell. Hard to believe isn't it. This is surely a day to mark on your calendar.

Next week I'm travelling to Ottawa (Tuesday) and then Vancouver (Thursday) to do some boot camp training on Visual Studio Team System. This 1 day hands on, gives folks a chance to play with the new modelling and testing features. I'll also be demoing the project management, process guidance, and integrated source control management features. If you are interested, there are still seats left. Click here for details and here for registration.