Paolo Pialorsi - Bridge The Gap!

CryptoAPI and DPAPI are not thread-safe :-( !

Today, while stress-testing a Web Application of a customer of mine, I discovered an issue in a piece of code working with DPAPI: CryptoAPI are not thread-safe!

As my friend and colleague Marco discovered through this Microsoft newsgroup post it's an issue "by design".

So, in order to avoid this problem, I had to review my code (originally based on MSDN DPAPI C# sample library) in order to provide a synchronization logic by myself.

The problem doesn't matter situations in which you use DPAPI just to protect gobal one-time-read informations like connection string and process impersonation identities, even if I suggest you to acquire a lock on resources before accessing them. On the other side it becomes an annoying issue if you use DPAPI intensively and with multiple threads, like in my application.

SQL Server 2005 Web Services (DAT329)

The session covered clearly the new features of SQL Server 2005 in the fields of Web Services support.

Key features showed were:

• Requires Windows Server 2003 or Windows XP due to HTTP.SYS kernel mode driver
• No requirements for IIS
• Configuration: Endpoint + supported operations
• It works on different kind of ports that are configurable: clear_port, ssl_port
• Security is implemented and enforced by design:
• Anonymous and Basic Authentication, requires ssl_port. Basic Authenticaton over clear_port simply doesn't work, the SQL statement fails if you try to do it
• Integrated and Digest authentication, supports both of the ports
• WS-Security support for UsernameToken (only in Beta 2)
• We can restrict access to the endpoint based on IP address filters (RESTRICT_IP and ALLOW_IP options)
• WebMethods can map to SP or UDF
• We can expose not only SP that SELECT data FOR XML, but also standard SELECT statements
• Result depens on FORMAT: ALL_RESULTS or ROWSET_ONLY
• BATCHES=ENABLED allows any SQL statement via SOAP
• Very dangerous!!
• The URL can be invoked with querystring parameters: ?WSDL and ?WSDLSIMPLE
• WSDL: contains the description of all SQL types
• WSDLSIMPLE: provides only description of the service
• Customizable WSDL: very good! We can define custom SP and make SQL invoke them, overriding the default way of working of SQL engine
• For SP and BatchCommands we can get as result an array of objects (FORMAT=ALL_RESULTS) or a DataSets (FORMAT=ROWSET_ONLY)
• Only members of the sysadmin role can create endpoints. There's also a CREATE ENDPOINT permission configurable
• Only members of sysadmin, owners of endpoint and users with CONNECT permission assigned can access endpoints
• Compatibility test done against many different types of SOAP clients (AXIS, JBuilder9 that is the same as AXIS :-), GLUE, SoapToolkit 3.0, and others) and also compliancy with WS-I BP1 (sounds good)

Personally I really don't like the idea to call SQL Server using a Web Service directly from the client, because we loose any opportunity to decouple, scale, architect our apps, etc.

I think that it's better to use SQLXML functionalities, only when are necessary, through a BIZ layer, rather than from a client.

The session demos were all about direct access to SQL from clients (SELECT * of rows into DataGrid and MessageBox) ... not so good, sorry about that. By the way the session was about SQL 2005 WS, not about distributed apps architecture ...

My last consideration is that I'd like to have full support for SOAP Messaging, using protocols different than HTTP/HTTPS.

Creating Efficient, High Performance XML Web Services (DEV319)

It was a very good session Christian, one of the best in this TechEd! I'd like to see a little bit more of demos, just to convince the people in the room, not for me :-), that I already totally agree with you. I really apreciated the agenda of the session and the ideas expressed. You confirmed in my mind many of the ideas that I've already had and suggested to my customers, but above all you confirmed me that I'm on the right way. Here are the main rules expressed:

• Schema first, contract first
• Use caching whenever is possible, but not always, keep in mind that real time data cannot be and should not be cached
• Asynchronous Web Services:
• Call web services asynchronously from Windows Forms apps, always!, with callback well-designed (using custom Delegates or at least MethodInvoker)
• Call web services asynchronously from Web Forms apps very carefully, mind the ThreadPool, avoid callbacks in order to not charge the ThreadPool. Consider PreHttpRequestHandler to improve performance
• On the service side (not server side!) consider Begin/End[WebMethod] paradigm very carefully. Use it only when you completely own the subject. Don't call it to use an async delegate or you'll quickly finish your ThreadPool threads ... [Who was in Bologna or in Naples for DevCon knows that I completely agree with this point of view!]

• Remember that ASP.NET process/AppDomain can be recycled, use external worker processes (ES, MSMQ, Queued components, etc.) in order to handle long running tasks
• Use doc/literal bare messages

During the session Christian spoke about Mvp.Xml a project, hosted on SourceForge, in which he is working with other guys of the XML world: I've already downloaded it!

There was a demo about a SoapExtension to compress SOAP traffic. To tell the true I'm a little bit sceptical about this. Of course its usefull in some scenarios, but you completely loose interoperability challenges ... as always it depends, but usually I'm not so convinced to use these technique. On the other side, as also Christian showed us, I often consider the use of a Validation SoapExtension, especially when working in the interoperability range. Even if XSD validation introduces a little bit of overhead, without it we won't have any kind of real validation of messages, we'll have just to trust XmlSerializer rules.

Great job Christian!

Third day at TechEd

To tell the true, today was not so exciting! The only two good session that I've attended were the one of ClemensV "Best Practices for State Management at Multiple Layers (CTS404)" and the one of Mike Fitzmaurice about "Programmatic Access To SharePoint Lists And Document Libraries (BPR377)".

The real sad part of today was that KeithBa wasn't here ... I was waiting for his session about reliability with .NET but he wasn't here :-( !

There are no particular considerations about everything else. I spent a lot of time in the MVP/MCT Lounge, because there weren't other really appealing sessions. Hope tomorrow will be better. I'm waiting for session about Web Services performance with Christian Weyer, tomorrow at 8.30 in the morning (hope to wake up on time :-) ... if I'll be late, please Christian forgive me :-) !).