Greg Reinacker’s Weblog

Congratulations to Sandra Bullock for being E! Online’s most eligible bachelorette.  I’m posting this in the hopes that maybe she’ll read this, think I must be the nicest guy ever, and call me.  :-)

And really, I think Britney Spears got robbed – #22?  Britney, you can call too.

Sorry for the off-topic ramble…but we can’t talk about .NET and web services all the time!

I was working with Greg’s authentication samples at work and I discovered a very irritating behavior with IIS on XP Professional. It seems that Digest Authentication is on by default, and the management UI doesn’t allow you to shut it off.

After some experimentation (and Greg’s suggestion), I determined that you can use the IIS ADSI interface to shut off Digest. Here’s a little bit of VBScript that does the trick on the root of the site: [...]

[Gordon Weakliem's Radio Weblog]

Thanks for posting this, Gordon.  It’s worth noting that this behavior only occurs on Windows XP machines that are members of a domain; stand-alone machines do not have the problem.  I have updated the original article with this info.

I know we’ve all been waiting for this!  Microsoft’s .NET class libraries for implementation of WS-Security, WS-Routing, DIME, and WS-Attachments.

“There is very little reason for folks to quibble over programming models when the choice is rpc/enc or rpc/lit, but the difference between doc and rpc is clear, it’s the choice between send(document) vs someOperation(parameters[]).  The programming model does matter.” [snellspace]

I disagree there’s a difference between doc and rpc. Your comment shows that you’re paying too much attention to the fact that that WSDL portTypes have an element call with a name. Let’s rename that to “” with an optional name for now. The reason the name was put in was so that you could refer to it later for bindings. However, there was NEVER any intent that the name would actually show up in the actual wire message. So, again we’re down to “how do you want to program to that service?” Some like to program with XML directly – so then generate a send(org.w3c.dom.Document) method. If you want to deal with language objects, map that schema to a language type and generate a method that has that as an argument. What’s the difference between the two? None, I maintain.  [Sanjiva Weerawarana's Radio Weblog]

I agree with parts of both of the above.  First, I think there is a philosophical difference between RPC-style and document-style API’s.  As mentioned above, there really is a difference (to the API consumer) between send(document) and send(parameters[]).  It’s subtle, but for certain classes of problems it’s a real difference.  It may not be programmatically/syntactically different in some cases, but it might be a different manner of thinking.

Now on the other hand, I think this is all pretty orthogonal to the difference between rpc/encoded and document/literal.  You can certainly build a RPC-style web service using doc/literal encoding.  Your RPC messages will be defined via schema, rather than section 5 encoding, but the end result can certainly be the same.  To me, the encoding style specified in the WSDL defines the message format; but not the API “style”.

So I’m sitting here thinking about What makes a Great Developer.

Now just to poke a bit of fun ;-)

I quote – “A lean company needs to make sure that they hire only the most productive, self-directed, and creative development staff possible”. I’m wondering, does a company ever state “Let’s hire the least productive, wanderers, who couldn’t have an original thought if it was implanted in their brain”? ;-)

Seriously though. All companies want to hire the best.  [News from the Forest]

Well, at many large companies I’ve worked with (with a couple notable exceptions), they will hire “average” developers, simply because they have a need to staff up quickly and they can’t take the time to look for the “best”.  My philosophy is the opposite; if someone who’s really, really good appears on your doorstep, you’d better try to hire him (her) whether you need to staff up or not; because if you don’t, he’s (she’s) not going to be available tomorrow.  You also better come up with something exciting for them to work on.  Of course there are business issues with this, and it may not apply in all situations…

But if you can build a team comprised solely of really, really good people, you can do some amazing things.

An answer (only partially quoted here) from Justin (red emphasis is mine):

That is the long answer – the short answer is I don’t know that I WANT a tolerant web service. I’m just seeing what they have to offer.

Now one place that I have been using a lot of tolerant web services is when it comes to people putting data into our platform. We have a baseline of information that we support. But we are going to allow people to add in extra data (insurance policy numbers, driver IDs, etc.). This has to be open and extensible. I have to be tolerant of stuff coming in that I don’t understand. I do this today with XML Schema “any” construct. This is very similar to .NET My Services. What are the colors? blue for predefined required elements, red for predefined optional elements, and black for unknown. .NET My Services won’t allow you to use black elements in queries. My system does (well…it will :-) .NET My Services introduced me to HSDL which is much more feature complete than what I was working on. So I dumped mine and moved onto it.

That is the best example of a tolerant system that I can think of. But again the tolerance comes from a well known point in the XML. So maybe that isn’t a good definition of tolerant. [News from the Forest]

Hopefully I didn’t trim this so much that I changed his meaning; I encourage you to read his whole response.  The points I highlighted in red are describing a xsd:any schema element, where the document extensibility (“tolerance”) would occur.  This is all I’ve been advocating…be extensible, be tolerant, but draw the line in the sand with your schema.

And hopefully Gordon doesn’t have a #FF0000 filter on his news aggregator.  :-)

Don talks about The dark side of tolerance. While there is no standard that I know of, I have been using a homegrown header for warning users of bad XML. I’ve built some fairly tolerant web services in the past few months for my own research.

For example, I allow you to post data as an element or an attribute, and I’ll grab the data from which ever one is present. If both are present, I grab the attribute and warn them that there was duplicate data in an element.

If they pass in elements or attributes that I don’t understand, I list them all out in a return header for them to see.

This all works pretty well. Right now I’m only handling extra data, duplicate data, and pulling data from multiple sources (element or attribute).

I did all this to answer a question. How tolerant should I be? [News from the Forest]

I’m still not convinced.  This related to the loosely coupled web services discussion we’ve been having, and I’m still not convinced that we shouldn’t be doing a schema validation on the input to our web services.  If you want extensibility, use a xsd:any extensibility node; if you want parameters to be optional, mark them as such with minOccurs=’0′. 

Justin, what is your reasoning behind wanting to have your web service be tolerant of what might be described as malformed input?

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.