I had Groove running on my notebook and I brought it up a few times to do things. I collaborate with some clients and people with Groove, keeping documents and discussions in sync. I also use it as a better Briefcase. And invariably, the comments were like “Wow, that’s cool! I could manage my distributed project that way. I could keep track of bugs across a geographically disperse team that way. And man, you’re disconnected and can sync later?” Then all of them would say “Who’s Groove?” Its interesting to note that people need this kind of stuff and they have no idea its even out there or who Groove is (none of the developers in the room had ever heard of them). […] How do we get people to collaborate? [Sam Gentile’s Radio Weblog]

It was Sam’s post (partially quoted) that made me start looking into Groove.  From reading other earlier posts about it, I just didn’t get it.  Well, this morning I spent a half hour or so on Groove’s web site, and I still didn’t get it.  If I hadn’t heard so much hype on the blogs about it, I would have quit right there.

So then I download and install Groove, and start playing with it.  After 15 or 20 minutes of this, I’m starting to get it, so I think.  I call a few people from a client’s office and get them to install it, and we start exploring what we can do.  By now, I’m getting excited about what I can do with this, and I’m starting to think I get it.  We figure out a couple of quick wins, and share a “pilot” groove space out to the team.

Now after a few hours of reflection, I think I only get the very surface of this.  This is such a great idea, and seems to be a great implementation.  But I think the potential of this product and idea is limitless.  There is so much you could build this way, so many ways you could collaborate with your team…I need some time to get my head around it.  For some reason I’m reminded of a post a while back from Ingo Rammer, where he’s talking about idempotent web services.  The possibilities here are, methinks, endless.  Anyone have any cool ideas?

Time for a Friday Five, since it’s about cars (something I love more than software development!).  [The .NET Guy]

I’m with you – completely a car guy.  My answers:

1. Do you have a car? If so, what kind of car is it? Well, my fun, non-daily-driver is a 1989 Ferrari 348.  Very impractical, but oh so fun!

2. Do you drive very often? Unfortunately not in the Ferrari; a couple of times a week right now, much less in the winter.  It’s almost a crime how much it sits in the garage.  In my daily driver car, yes – I drive a lot.

3. What’s your dream car? That’s hard to say…right now, for a street car, I’d say a Ferrari Enzo, which will be shipped later this year (all 300 or so of them).  For a race car, a F1 car would have to top the list.

4. Have you ever received a ticket? Yep.

5. Have you ever been in an accident? Not recently, but yes – although my accidents on the street haven’t been my fault.  On the race track (more recently), a different story – probably 50/50 between my fault and not.

The original question is “When you model data access, does the model represent the data and its relationships, or does it represent the specific queries you know you wish to make?”

The first thing I would like to state is I don’t like to think of my data access in terms of queries. I think of my data access in terms of transactions. I might only return one set of data, but I might have performed 10 other queries underneath that builds that set of data.

So to answer the first question – I model my data access after the transaction I’m going to perform. I do this for mainly for performance. I used to do object models because the OO guy in me wouldn’t let go. But the reality of scalability came crashing down on me.  [News from the Forest]

This is a great read from Justin (only partially quoted above).  I’ve run into many clients who build their data layer as “one class per table”, and I really think that’s the wrong way to go in many cases.  If you’re trying to build a scalable system, it’s all about transactions, baby…and keeping them short (don’t hold locks for a long time) and simple (hold as few locks as possible), which the “class per table” system does not inherently lend itself well to.

MSDN Article: HTTP Security and ASP.NET Web Services

There’s a new article up over on the MSDN site that discusses various aspects of HTTP security for ASP.NET based web services. [Drew’s Blog]

Thanks for the pointer, Drew; a good introductory article, about which I have a couple of quick comments.  First, the author only discusses authenticating with Basic/Digest/Certificates against the Active Directory store; probably because this is all IIS supports out of the box.  This isn’t a fault of the article; but people should be aware there are other options.  There are numerous reasons you might want your credential store somewhere else (existing database, etc.); to do this, you have to write the code yourself (or use my sample code).

Second, there is a sentence in the article I just can’t let go:

Digest authentication encrypts the caller’s credentials using a shared secret called a nonce.

Hmm…Digest authentication does not encrypt the caller’s credentials; it hashes them.  That’s why the credentials (or at least a hashed version) must be available on the server for authentication to occur (as opposed to something like NTLM, where the password itself is not required on the server).  And second, the nonce is not a shared secret; it’s passed clear-text – not much of a secret!

I was out racing this weekend, and won my first national race…

Congratulations Greg! I’m curious — how did you get into that? Have you been a car/racing fan for a while? [Wrinkled Paper]

Thanks Patrick!  I’ve always been into cars, and since I could drive, I always wanted to know what it felt like to drive at the limit of a car’s capabilities (I was, ahem, familiar with both sides of that limit, but not the limit itself!).  With that in mind, I finally (2 years ago) talked a friend into going with me to Bob Bondurant’s racing school, where we learned about high-performance driving and road racing techniques.  After that I was hooked…on my instructor’s recommendation, I called the LaRue’s (of LaRue Motorsports) and rented a race car for a day, just to see if I liked it.  Two days later I entered my first SCCA race in the rented car; after that weekend I bought a car, and have been racing ever since.

It’s been an amazing experience; and it’s certainly had its ups and downs.  It hits the extremes of exciting, frustrating, rewarding, dangerous, and expensive.  It makes you explore the limits of not only the car, but yourself.  I never really appreciated the skills and conditioning of race drivers before I tried it myself.  If you’re a car guy/girl, I highly recommend trying it (a school would be the best way, or just renting a car for an open track session); it’s something you’ll never forget.  :-)

I was out racing this weekend, and won my first national race.  And not just one…I won TWO of them!  Talk about the best racing weekend ever.  I had pretty much ruled it out, but now I’m thinking again about going to the national championship (the Valvoline Runoffs).

XML Schema derivation by extension superfluous?. Don falls for derivation by restriction one more time. [Don Box’s Spoutlet]

While I was just trying to round out some ideas related to the schema and web services discussion we’ve been having, I came across this post from Don.  Very pertinent to what we’re talking about, relative to extending a schema when it contains xsd:any extensibility elements.

When we derive by restriction, we are guaranteed that any valid document matching the new schema will also validate against the original schema.  This is what I was trying to describe below…just not as succinctly as I might have.

New essay: Expect More.  [Sam Ruby]

Sam writes an excellent essay on upward and downward compatibility with web service contracts.  If I might paraphrase for context, he holds that we should be able to add or remove parameters from a web service contract, without adversely affecting existing clients (note he says a lot more than this – read the article!).

I tentatively agree with Sam; but only in the case where the new request can be validated by the WSDL-contained schema.  If you send me a new element I’ve never heard of, and I can’t validate your request document against my schema, I don’t consider it a valid request.  If you omit something, and my schema says it’s required, invalid again.

Here’s an example of where I believe your rules could get you in trouble.  Suppose a service to book an airline flight (coach only in v1), with the request schema:

<s:schema targetNamespace=”http://sample.org/“>
  <s:element name=”BookFlight”>
    <s:complexType>
      <s:sequence>
        <s:element minOccurs=”1″ maxOccurs=”1″ name=”Airline” type=”s:string” />
        <s:element minOccurs=”1″ maxOccurs=”1″ name=”FlightNum” type=”s:string” />
        <s:element minOccurs=”1″ maxOccurs=”1″ name=”Origin” type=”s:string” />
        <s:element minOccurs=”1″ maxOccurs=”1″ name=”Destination” type=”s:string” />
      </s:sequence>
    </s:complexType>
  </s:element>
</s:schema>

And a valid request document matching the above schema (SOAP headers omitted):

<BookFlight>
  <Airline>UA</Airline>
  <FlightNum>1234</FlightNum>
  <Origin>DEN</Origin>
  <Destination>SEA</Destination>
</BookFlight>

Now suppose you send me a document that also includes a “ClassOfService” element:

<BookFlight>
  <Airline>UA</Airline>
  <FlightNum>1234</FlightNum>
  <Origin>DEN</Origin>
  <Destination>SEA</Destination>
  <ClassOfService>First</ClassOfService>
</BookFlight>

As I read Sam’s rules, this should be allowed and be processed exactly as before.  Now, suppose version 2 of my flight booking service supports booking in first class as well as coach.  If I add a “ClassOfService” element, which takes ‘F’ or ‘Y’ as the parameter, your document may now give unexpected behavior. 

For cases like these (and many more that I could come up with), I believe that loosely relying on the schema is a bad idea.  I think you should only extend the request in places where the schema specifically allows it; in the case above, if there was a xml:any extensibility element, you’d be fine, and you could put your extensions there.  If you want to omit parameters, you can only omit the ones allowed by the schema.

Sam mentions explicit extensibility points at the end of his article, but I got the impression he meant that while these were a good idea, we should allow the request extensibility even without these mechanisms.  Very-loose coupling might be ok when we’re searching for books; but when we’re doing financial transactions or other sensitive transactions, I think we need to be very specific about what we’re doing.

Otherwise, I think that’s just asking for trouble.

Wow, who knew…my managed HTTP authentication samples are on the “Cool Stuff” list at 123aspx.com.  I mean, sure, I thought they were cool :-)…but I didn’t know it would be a popular thing!

Regarding my previous post about adding methods to web services without changing the version/namespace, Brad had a good comment:

The thing you have to be careful with is new clients against old servers. While the consequences aren’t necessarily as severe (crashing w/ an access violation is bad :), they still need to be planned for. [The .NET Guy]

Right, when I wrote my blurb I was thinking about the case where you are directly responsible for every endpoint implementing your interface.  The other case is when you define an interface, and then multiple companies implement your interface in a web service; in this second case, I would agree with Clemens’ rule that the namespace should be changed if a method is added, to avoid the problem Brad points out.