Softwaremaker, Benjamin Mitchell, Sam Gentile and some others have been having a conversation about Indigo. I wanted to chime in on a particular point Benjamin made about Indigo that is also about WSE which is building up to Indigo.

one of the reasons I’m so excited about Indigo is this focus on designing the programming model with developer usability as a goal.

Hey, he’s talking about me (and you). I know I have put myself in the role of guinea pig here because I am “the developer”. I am the developer and not the plumber so although I am darned good at writing software, I have to put a lot more effort in to comprehending what’s going on in the background – and many developers will never even bother with that effort because it is sadly a big one.

So making the programming model intuitive enough and streamlined enough that developers can latch onto it easily and then our software can a) benefit from what is going into these tools and b) participate in interop if that’s where we are working. But if you are already a plumber, it’s pretty hard to grok what is and isn’t comprehensible to a non-plumber. I am really working at trying to understand this stuff, trying to translate it to others so they won’t have to put so much effort in and also trying to let Microsoft know when something just IS NOT accessible, when I work REALLY hard and I STILL am not getting it. I wish I had had the time to do this before WSE2 was released, but sadly I didn’t.

There has got to be a place somewhere in between “way too hard for me to spend the time figuring out” and “just click a few buttons and you have access to 10% of the features but not anything else”.  I know they are working on it. The programming model is pretty intuitive and really, once you get the basic chore down: create the different types of security tokens you are going to use in your messaging, add them to the soapcontext of your web service, define the elements you are going to use to secure your message and assign the proper one of your tokens to the elements, then add those elements to the soapcontext and go. There is a layer of WSE2 that will simply answer the needs of many applications. It’s only when you try to move away from that layer do you (well, if you are me) get in trouble.

Right now the pain I’m feeling is in the area of working outside of the simplicity of using x509 certificates. I haven’t even gotten much further than the basics. I haven’t even considered interop yet. I’m just writing the front and back ends in .net and trying to get them working together in a variety of scenarios.

So what’s my point here? Something about the fact that yes, they are definitely getting there, because I, Julie Lerman, can actually use WSE2 (although I did work really hard to get myself to the not-even-very-impressive-point that I’m at right now) and if they can just keep going on this same path between WSE2 and the future WSEs that we get up until Indigo, I bet we’ll be in damned fine shape.

Oh and there was one other thing I wanted to comment on which is the perspective that William (Softwaremaker) writes about in his post – about focusing on Interoperability. The funny thing for me is that I am not even LOOKING at interop. At the moment I don’t happen to need it with the applications I am working on. I am not trying to learn this stuff so that I can do interop, rather because one of the side benefits of all of this work that everyone is doing with ws-* in order to make interop work more fluidly and efficiently is that we can also leverage these tools in our proprietary applications (hmm – what is the word for non-interop?). I’ve got .net on both ends of my pipe. I’m not interoping with myself or anyone else. I’m not disagreeing in any way with William as I have no experience in that space at all. I just find it intersting that the real purpose behind WSE and Indigo is for interop, hell the real purpose behind web services is interop, but these tools (well obviously not Indigo yet) are the most important players in my application architecture anyway.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!