XML Eye for the Object Guy

Posting again!

MSDNArchive — Mon, 28 Jun 2004 21:50:00 GMT

But at a new location: http://www.pluralsite.com/tewald/default.aspx.

Post-PDC pondering...

MSDNArchive — Thu, 06 Nov 2003 04:48:00 GMT

Back from PDC, mailbox dealt with, finally some time to post...

As David observes, for many of us last week was a wonderful whirlwind of Indigo and Don, blended together from Monday through Thursday. Here are some thoughts...

Like everyone I know, I'm in love with Indigo. The reason is simple: the layered API hits the sweet spot. It used to be that building distributed apps meant writing sockets code. Then along came RPC and object RPC systems that encapsulated grungy details behind a programming model. Hiding the details was good, the programming model was okay - except when it wasn't. Unfortunately, with those frameworks, you didn't have much choice. Indigo, in contrast, layers functionality so that hiding the grungy communication details doesn't mandate a particular high-level programming model. You get security, reliability, transactions, etc., whether you choose to deal directly with XML messages, map message bodies to object models, use simple request/response message exchange patterns or something more complex, or whatever. In short, you can build communication models the way you want without having to go back to sockets and do everything yourself. That is exactly where I want to be.

Don's talk introducing SOA on Monday afternoon was the best one I've seen him give in a long time. I've learned a lot about being a speaker from Don and it was great to see him deliver that performance.

Finally, I had the pleasure of spending time with Steve Lucco, who works on Indigo with Don. Steve joined my wife Sarah as a lead vocalist in Band on the Runtime. He's really really smart and a great guy to hang out with. (Also, Steve's rendition of CPU Bound gets my vote for most hummable BotR tune, it's been stuck in my head for days.)

Speaking at PDC

MSDNArchive — Wed, 01 Oct 2003 03:01:00 GMT

Cleaning out my inbox after vacation, I find a note pointing me to this post from Brian Jackson, wondering if I'll be speaking at PDC. Yes, and I'm looking forward to it. Don, Martin and I are going to deliver the pre-conference tutorial on XML and Web services. It'll be just like the old days... :-)

Sharing the fruits of summer's labors

MSDNArchive — Sat, 20 Sep 2003 00:23:00 GMT

I did a lot of XML work over the summer. One of the byproducts was a pair of XML readers. The XmlElementReader wraps an XmlReader that is positioned on an Element node and allows you to read that element, but nothing more. It's useful for passing an XmlReader to a method, but ensuring that it only consumes the current element and nothing more. The XmlInscopeNamespaceReader also wraps an XmlReader. It provides a method to lookup all of prefix/namespace URI bindings that are inscope at any given time.

I'm on MSDN TV

MSDNArchive — Fri, 19 Sep 2003 23:51:00 GMT

As Craig noted, my talk from the Applied XML DevCon in Portland, OR last August is now online courtesy of MSDN TV! It's in two parts, here are links to part 1 and part 2. I had a great time at that show, and this was a really fun talk and had a big impact on people (like Rich, who mentions it here). Lot's of people at the show and via email have asked for more info about the ideas I talked about. I haven't had time to write something up yet, I'm hoping to do it when I'm back from next week's vacation.

I need to clarify...

MSDNArchive — Fri, 12 Sep 2003 21:47:00 GMT

Reading Micheal M's comment, I realized that I was not clear enough in my last post.When I said I didn't want to think about security, I meant as a plumber. Part of my responsibility as the designer or developer of an application is, as Micheal M, says, to think about everything as a possible security hole. He is absolutely right and I did not intend to imply otherwise.

But I need help. I can't write my own cryptography engine. I don't have the time, and, more importantly, I won't get it right. Similarly, I don't want to have to write my own SSL hand-shake to establish a secure channel with an HTTPS endpoint. Luckly, those things are provided for me by my platform. However, that doesn't mean I get to abdicate all responsibility. At the very least, I have to:

Make sure I understand how these technologies work and I know how to use them correctly
Decide how to use these technologies to my application so that I ensure data integrity and confidentiality wherever it's required
Make sure I test my application to ensure that the technology does what I expect it to
Make sure I keep my platform up-to-date with patches that fix security holes

SSL strikes a reasonable balance. I don't have to worry about implementing the cryptography or handshake protocol myself. I do have to worry about when and how I use it, keeping my implementation patched, and whether or not the cert presented to the client does in fact identify the server. That's tractable for me with my level of security expertise.

My point about WS-Security and all the threads about MsComServices was that I need to get more from my platform. I want to get replay detection and secure channels from my platform. As with SSL, I will still have to think long and hard about how and when to use these features, make sure I keep my implementation up-to-date, and test my implementation to make sure it works. But I won't have to implement everything myself.

Things are moving in the right direction with the WSE 2.0 Tech Preview. WSE 1.0 provided the atoms for WS-Security. 2.0 provides molecules like WS-SecureConversation. Increasing the level of abstraction in this way is key.

Thanks for raising this point Micheal. I don't wany anyone to think that I or anyone else at Microsoft is not VERY concerned about making software more secure. Ironically, I actually see removing myself from the lower level implementation details as a way to increase the security of my software. Using the right security features from my platform is a better choice, as long as I do so responsibly (see the bullet list above).

"But I'm a plumber..."

MSDNArchive — Thu, 11 Sep 2003 09:48:00 GMT

I've spent a lot of time with WS-Security lately, partly because of the bruhaha over its use in MsComService, and partly because I'm digging more deeply into WSE 2.0. Like most of my friends (and a penguin Gudge knows), I'm a plumber. I like spending time thinking about how to program with XML messages (feeding my reputed addition). But I realized last weekend that there are limits, even for me. I realized that I want someone else to take care of security for me...

It's not that I'm not interested - I think it's a fascinating topic. But I have too many other things going on to lose myself in it, and I don't trust myself to build something secure if I have to worry about all the details of signing, encryption, nonces, hashes, etc. myself. Hopefully a day will soon come when I can simply request a secure channel to a distant service and sit back and relax, confident that someone else has thought about the hard security problems for me.

Then I can spend more time thinking about what the bodies of my message look like - the problem domain specific part that it's hard for other folks to help me with...

Changes in the works...

MSDNArchive — Thu, 11 Sep 2003 09:36:00 GMT

Sam welcomed me back to the blogosphere...

Your points are well taken. People here are very aware of the fact that developers may well look to Microsoft.com's services as an example to emulate, so they try to make sure they do the right thing. In this case, there's a been a lot of confusion around the fact that WS-Security really offers levels of protection and, in this case, the level required is pretty low. That said, the guys who built the service are working on the details for replay detection. I'll keep you posted as I find out more...

In the same thread, Dare commented that the use of WS-Security in this context doesn't make sense to him and that a token like the one used in the Google service makes more sense to him. The problem with adding a token to every operation is that it goes in the body of the message. Since the goal in microsoft.com's case is to consume the token at a router that then passes the message on, it needs to be in a header so as to avoid violating the SOAP processing rules. Once you're using a header, you've got more code to write in any case. Given that, why not use an existing header that identifies users? I think it would have been more confusing if they'd made up some new header of their own...

One more thing...

MSDNArchive — Fri, 05 Sep 2003 04:10:00 GMT

Someone pointed out that signing a message wouldn't actually solve the all the issues Simon raised. It would stop someone from tampering with a message, but it wouldn't stop someone from replaying a message. You need to take additional steps to protect against that as noted on this thread at Sam Ruby's blog.

However, the real point I was trying to make on behalf of the developers at Microsoft.com who built this prototype service, is that security wasn't really their goal.

Using UsernameToken with the new microsoft.com Web service

MSDNArchive — Thu, 04 Sep 2003 03:07:00 GMT

I spent my summer deep in an engineering project, the purpose of which will come to light in coming months. Now that the first phase of that work is complete, I have time to start posting again. And what better place to start than by answering questions raised by Simon Fell's recent post about the use of WS-Security with the new Microsoft.com web services.

Some of the guys at microsoft.com spent their summer working on the server-side infrastructure they need in place to support production Web service. They recently launched a prototype service that's intended to vet the plumbing. To use the service, developers have to register and get a username and password. Request messages carry a WS-Security UsernameToken containing the username and a digest based on the password, a nonce, etc.. Simon points out that, because the message is not signed, it doesn't provide any security. He's right, but that really isn't the intent. Rather, the UsernameToken is used like a cookie. It tracks invocations to gather metrics about how the services are used and to throttle requests so that servers aren't overwhelmed. The goal is to test the server plumbing and get a sense of how people use it. Google and Amazon do similar things with their public services.

So, why use a WS-Security header to do this? The service designers felt that a header would be preferable to an extra parameter on every call. A SOAP header made more sense than an HTTP header, because, long-term it is likely that messages will end up being routed on the server side for a range of operational and deployment reasons. Given that, WS-Security's UsernameToken mechanism seemed to fit the bill. They thought about requiring messages to be signed with the token to help protect against swiped tokens, modified messages, etc. They decided against signing for several reasons:

the service is read-only
there's no private data to protect
requiring signing would make it much harder to build message from any toolkit that doesn't support WS-Security

From my perspective, the last issue is the most significant. It's pretty easy to layer in a UsernameToken with a password digest with a toolkit that has no knowledge of WS-Security (like this Python client). It's harder to layer in XMLDSIG support.

The people who maintain the new service's web site are working on updating the text there to make it clearer that the service is not intended to be secure. (They're also working on posting the documentation for the service online.) Beyond that, there are two other changes they could make. FIrst, they could modify the service to require a signature, thereby mitigating the issues Simon raised. However, that would make consuming the service from any non-XMLDSIG enabled toolkit essentially impossible. Alternatively, they could change the service to use some other header that people don't associate with security, e.g., . It isn't clear to me yet that either of those changes makes sense. But people here are definitely listening to your feedback!

What to wear under your IBM power suit

MSDNArchive — Tue, 06 May 2003 09:40:00 GMT

I heard a rumor that Grady now has a pair of Don's Boxers. COM really was about love… :-)

Welcome Chris!

MSDNArchive — Wed, 23 Apr 2003 06:07:00 GMT

Chris and I worked together for years at DevelopMentor, and now he has joined my team at Microsoft. I'm very much looking forward to working with him again!

Handling mandatory SOAP headers in ASP.NET

MSDNArchive — Fri, 18 Apr 2003 11:19:00 GMT

My latest House of Web Services column is now online here. It explains how to fix an issue mandatory header handling in ASP.NET. Sample code is also available.

Forgive me...

MSDNArchive — Wed, 09 Apr 2003 11:42:00 GMT

Forgive me, bloggers, for I have sinned; it has been eight days since my last posting...

Actually, I've been stuck in Word writing specs. But soon, soon I'll be writing code again! :-)

Epiphanizing with Don

MSDNArchive — Wed, 09 Apr 2003 11:42:00 GMT

After spending all day at an offsite for my new project, I went out to dinner with a member of my team, and eventually ended up back at Don's house. He was on fire, so we headed back into the office, where there are plenty of whiteboards. As is often the case, he was in the middle of an epiphany about XML APIs and I helped him work through some of his ideas. It was a blast - just like the old days. :-)

I'm very optimistic about the future of XML. I haven't yet commented on all the recent posts about XML's relative suckiness or lack there of. Two things are clear to me: (most of) the basic protocol stack and APIs we have today are totally reasonable, and we can do a lot better (at least where APIs are concerned). As I said way back when, there's a ton of work to do here.

A shortcut I learned today

MSDNArchive — Wed, 09 Apr 2003 11:42:00 GMT

I mentioned a few posts ago that I'd been spending all my time writing specs lately.

One side benefit is that Tommy Williams told me that Word maps the 'F4' key to the last operation you completed. If you are deleting rows from a table (Alt-A, D, R), F4 saves you a lot of keystrokes. Maybe everyone else in the world new about this (if so, why didn't you tell me?), but it was a new to me, and very useful.

RSS at MSDN!

MSDNArchive — Tue, 01 Apr 2003 08:04:00 GMT

MSDN finally has official RSS feeds!

Here are the URIs:

We've already started getting requests for features, like categories. We have lot of work to do on our internal systems to get some of this stuff working the way we want, so please bear with us! We have big plans for using RSS going forward!

Outbound from Seattle...

MSDNArchive — Fri, 21 Mar 2003 05:24:00 GMT

I've been on the road for most of the last 5 weeks, so it's good to be heading home. I've been a road warrior for most of the last 7 years, so I'm used to getting up early to catch a flight. This morning was no exception: I woke up, packed up, and rolled out for my 8:20am to Dulles. On the 520, I realized my car's clock read 3:20am. That's never happened before.

Five hours to kill. Pay-to-play airport wireless access never looked so good...

The airport access road had a security stop, a very brighly lit area with a tent, a stop line and officers in uniform. That's never happened before either. All the TV's in the terminal are showing CNN, and it's non-stop war coverage. To fill the time there are interest stories about the size, weight and speed of the M1A1 Abrams main battle tank. It is very surreal, almost like sports coverage. So far there have been few casualties reported on either side, which I'm thankful for...

Sorry for the somber tone, it's been a very strange morning...

If you read no other spec this year...

MSDNArchive — Fri, 21 Mar 2003 05:24:00 GMT

I haven't had time yet to say anything about the latest batch of WS specs. WS-Addressing is far and away my favorite. That's not to say that WS-ReliableMessaging is not very important, but WS-Addressing helps me make a point.

We all know that most developers think of Web services as an RPC mechanism - a view that the original SOAP spec and countless Web services toolkits reenforce. Happily, the recent work on SOAP embraces a more message-centric world view. Unhappily, this view hasn't yet permeated many people's thinking about WSDL. Much of the ongoing work in that area still seems to focus almost entirely on generating proxies that make RPC calls.

I think one of the reasons that the RPC model still dominates many people's thinking is that we really haven't gone beyond the HTTP binding defined in the first SOAP spec. For better or worse, as long as we are focused on a client-initiated request/response model, developers are going to think of it as RPC (even though HTTP deals in streamed bytes, not callstacks). WS-Addressing opens the door to other possibilities - like sending response messages to places other than the implicit port at the other end of the HTTP connection.

With a standard way to describe where messages are supposed to go, what their intent is, and how they relate to one another, we can start building systems that use SOAP messages in other ways (without the complexities of WS-Routings message paths). That in turn will start to influence WSDL. In short, WS-Addressing may be the forcing function we need to really start moving away from the the current RPC-centric view of the world into more interesting areas.

At least that's what I'm thinking at the moment. :-)

Accessing raw XML messages from an ASP.NET Web Service

MSDNArchive — Tue, 18 Mar 2003 05:11:00 GMT

My House of Web Services column about accessing raw XML SOAP messages in an ASP.NET Web service is now online at the MSDN Magazine site. The sample code is also online.

RSS vs. Blogging

MSDNArchive — Tue, 18 Mar 2003 05:11:00 GMT

Don't let Don fool you, he did plenty of talking during my meeting with Rael and Tim O'Reilly on Friday. We talked a lot about different ways to use RSS, both for blogs and other sites. Much of the conversation focused on RSS clients. The basic readers we have today are fine for browsing blogs, but what about organizing and filtering content from multiple feeds? There isn't a lot of client-side support for transforming metadata included in a feed into an alternate format, or merging data from feeds for searching, sorting, or presenting information. You can do all those things if you consume the feeds yourself, but most readers (at least the one's I've been using) don't support features like this. There is definitely a lot of interesting work to be done here!

Back in the saddle

MSDNArchive — Fri, 14 Mar 2003 04:39:00 GMT

My blog has moved from it's old location to this page. I'm making the change so that I can start using Don's latest public blogging engine, which is designed to prop posts much more quickly.

I'll do my best not to vanish into the dark again...

Bringing Web services to MSDN

MSDNArchive — Fri, 14 Mar 2003 04:39:00 GMT

I spent a couple hours this afternoon with Jeff Barr, evangalist for Amazon's Web services, and Tim O'Reilly and Rael Dornfest from O'Reilly. They came to talk to a bunch of folks from the MSDN and Microsoft.com teams about their experiences with public Web services (something we at MSDN care a lot about ;-).

The conversation was very interesting. One of the most interesting observations was that developers end up using public Web services in ways their creators can't predict or imagine, adding credence to the notion that intended usage should not be a limitation.

Another key point was scope and simplicity. This is, of course, a sticking point for a lot of people. Some people think REST and Perl are the easiest path, while others prefer proxies generated from WSDL. (Personally, I prefer C# and raw XML). It would be very interesting to expose both, as Amazon does, and let developers decide...

Back in the saddle

MSDNArchive — Thu, 13 Mar 2003 11:55:00 GMT

My blog has moved from it's old location to this page. I'm making the change so that I can start using Don's latest public blogging engine, which is designed to prop posts much more quickly.

I'll do my best not to vanish into the dark again...

Bringing Web services to MSDN

MSDNArchive — Thu, 13 Mar 2003 11:55:00 GMT