okay- I seem to have picked up this “jig” thing from Ted Neward, but I just noticed something – that is MUCH more obvious when working with code you know well, rather than fiddling little samples.

With WSE1.0, you have to modify your client’s proxy to the web service so that it inherits from Microsoft.Web.Services.WebServicesClientProtocol instead of the default System.Web.Services.Protocols.SoapHttpClientProtocol. Every time you update the web reference, you have to remember to go back into the proxy and make that change. I have gotten into the habit, but really it’s just one more thing I need to remember, cluttering up my brain.

I have just modified the client component that has been working with WSE1 to use WSE2. When I updated the web reference in that project, the inherited class was automatically changed to Microsoft.Web.Services2.WebServicesClientProtocol.

This makes me very happy. I can free up that little space in my brain now for more important things! And it is one less barrier to getting regular programmers to use this stuff. Thanks WSE folks!

(I should point out that you get TWO proxy classes and this happens to the WSE2 version…)

I am finally converting my web service login and authentication procedures for one of my big production apps. Currently it is using straight web services, with a combination of soap headers and a System.Web.Security.FormsAuthentication ticket which is returned to the client as an encrypted string to be sent back with future requests as well as cached on the server. Lastly, I have a little user class that stores some details about the user that are used for authorization on the client end.

It’s somewhat similar to a secure conversation model because my token also times out every two minutes and has to be regenerated, but I don’t have to authenticate on every single message.

But an interesting difference is that I am explicitly authenticating at the user login (like we always have done, right?) whereas with the ws-security model, I will authenticate along with my actual requests. So if I were CODING all of this (which I’m not sure if I choose between hand coding in order to drill the stuff in to my brain better, or if I will just use the config tool and let that and policies do the grunt work for me — and if you saw what a GORGEOUS day it is out – you’d probably vote for the latter, too! :-)) …where was that sentence? Oh yeah, I will basically strip out the authentication that happens at login.

Thereare some cases where I am doing application updating and I require authentication at login for that process also. But for the other apps, I get to just rip out SO MUCH CODE – yippee – on both the client side and the ws side. Currently, on the client side, I am stuffing the token in the header of every ws call, so I won’t have to do that any longer. On the ws side, every method takes that token and checks against the cache to see if it’s still valid. So I get to take that code out. If it’s not valid, I was returning nothing to my client and the client has to send back the login/pw (which is still available to the app) and get another token. So all *that* code can go, too.

Rip rip rip, delete delete delete.

VSLive lucked out when the hurricane diverted and missed Orlando. Now PASS, in Orlando next week, is dealing with Hurricane Jeanne. Watch PASS track chair Roman Rehak’s blog for updates. The SQLPass site also has information and links regarding the Hurricane.

There is an AP article that has been picked up by a lot of papers around the world and I’ll link to it on msnbc’s site. The article is about using quantum physics for encryption via photons (light particles) – rather than the keys (strings of random numbers) we use today. It’s pretty far out but not even totally new. There are a few companies already offering solutions (eg MagiQ Technologies) and Harvard is working on the availability on the web. Pretty amazing stuff. I guess in __ years from now, it will be as common as sliced bread.

I love doing this! I have to refactor some pieces of a big production application for a client. This also means stripping some functionality of the application and turning it into individual components which I have wanted to do, but could not justify billing my client for. But now I must do this in order to incorporate some new functionality that will also need access to this logic. Sometimes, working with “old code” is a huge bore, but this is fun because I’m making my code smarter and that makes me feel a little smarter.

When I first started looking at .NET, one of the new concepts that I kept running into was the “delegate” thingies. I kept seeing things written about them, but never walked away really understanding what they were. So it becamse my mission and the first time I really had a “DING!” go off in my head was an explanation in The Book of VB.NET by Matthew MacDonald. Unfortunately, I have long since passed this book on to someone in the user group so I can’t quote it.

Anyway, I thought of this because Avonelle mentioned delegates and the difficulty that she has had getting her head around them and pointed to this article on KnowdotNET that gave her the “aha!” moment.

I actually had a more interesting realization about delegates this summer at TechEd when I was doing a TabletPC Hands on Lab that was all in C#. I couldn’t understand why I had to keep writing so many delegates and then I realized that the delegates were creating event handlers! And THIS is why us VB background people have such a hard time grokking delegates. IN VB (past and .NET), event handlers come free. They are already there. If you drop a control onto a page, then you automatically have access to that controls list of events in your code. If you instantiate a class in your code, the class’s events are available in the dropdown. So we never had to use delegates (not even available to use before .NET anyway) and therefore they didn’t come naturally.

So you C++ and C# developers, next time your walking down the street and you see someone who is scratching their head muttering “delegates…I just don’t get it”, and you are kind enough to attempt to explain and they STILL don’t get it, don’t just shake your head and walk away. You need to relate them to something that already IS in VB so that they have a bridge. Event Handlers are that bridge.

update with just a little more goo: Just an FYI for you VB’ers. I’m working on converting a login form from VB to C# …oh the drudgery of solving casing problems! 🙂  Anyway, I thought I would point out that when you double click on a control to get it’s default event, C# automatically codes up the delegate in the InitializeComponent method. So I clicked on an OK button and not only did I get my event code but it’s delegate was auto generated as well (that’s backwards – because the delegate makes the event handler possible)
  this.btnOK.Click += new System.EventHandler(this.btnOK_Click);

So if you just consider the relationship between this delegate and the familiar event handler

it might help a bit…

…and recruiters? Well, yes, actually.

I was reading this post of Casey Chesnut’s where he is ranting about some of the annoying things recruiters do and says :

that disconnect being recruiters. you’ve got a high tech company on one end, then you’ve got technical workers on the other … and smack in the middle, somebody that does not know technology

I couldn’t help but think immediately of one of the SSL issues that is avoided with WS-Security. Things are secure when they are in the SSL pipe, but if you have an intermediary en route, your message has to exit the pipe and you can’t be sure that the intermediary is secure. With WS-Security, you *do* have end to end security as the sender and receiver are the only ones who can interpret the message.

So I had to laugh when Casey made that statement, because I just couldn’t help thinking of the somewhat skewed analogy!

Kasia’s got a funny post on being a geek.

I meant to do this after talking with a friend who has been contracting for only 2 years.

Except for a project that was through a consulting company, I have used the same base letter of agreement with clients for almost 20 years. I even used it when working with G.E. Capital – oh but maybe not 3M. It’s easy to understand. No lawyers need be deeply involved. It has been enough for everyone I have worked for.

I’ll try to remember to write more about it at some point.

I was having a hard time putting the different pieces of WS Security into buckets so that they are easier to explain.

The problem was authentication. I finally realized how I wanted to explain it. Authentication is done with security tokens, but authentication does not really belong in a bucket. It is done in tandem with all of the other processes – authorization, encryption, signing. Now it makes more sense to me.

I am starting to realize that one of the reasons that I have had such a difficult time with WSE is because I am not really a linear thinker. I’m more, well, spherical. But I was somehow unable to take wse as a whole and shove it into my brain. I really have had to go through this detailed process of breaking it apart, analyzing it’s pieces and then seeing how they fit back together.

And the sad part is all of this effort has only been for grokking the security stuff. There is a lot more to WSE than security.

The happy happy part is that I do really have a handle on this and one that I know I can easily share with other people who feel about this info the way I have for the past few years!

I seriously need to shout out to Don Smith for some hefty support over the last bunch of days. He’s been amazing in helping me clarify some of the things that I was still fuzzy with. THANKS DON!