>Sorry, Michel, but I'm failing to comprehend the purpose of your assertion in this context. Anyway, your first article did a good job in showing how to implement a standard compliant method of passing support/control information within the SOAP envelope (you demonstrated the case of user authentication, but there are uses for it, of course). In this respect, your 2nd article seems regressive to me.

Despite the fact that I did some research to implement the SOAP header manipulation approach last year, in order to benefit of some kind of mecanism to maintain a state, I never liked it. The problem with that approach is that it requires the client to manipulate it as well. If it would have been only for a few methods, we would have adopted an approach to pass additional parameters at each method call for the recognition. But, in our case, as the number of methods keep growing, that was not practical so we went for the SOAP header manipulation approach.

One think I didn't like about that is that, as oppose to a Web site application, where you can benefit of cookies and session variables, for example, that was not supported in SOAP 2 toolkit. So, as for that one, I did find that quite regressive. You probably have seen some of the threads on that topic in the last year. Basically, we were all waiting for something that would have been compliant with the way we use to work within a browser-Web server approach.

>Microsoft won't call it SOAP 3, ever.

Well, if this isn't called the SOAP 3 toolkit Beta than I must have missed something. I've been involved for while on that for a lot of testing and manipulation and I am extremely happy that this version does resolve those issues.