Integrated Authentication + Web Services

Today I ran into an interesting performance issue around using Integrated (Windows) Authentication when calling web services... or at least it was interesting to me because I ended up learning something. I have to admit that I haven't had much experience using Windows Authentication with a web service before, apart from maybe just testing whether various concepts worked.

On this particular day, however, I had to make a call around whether to make multiple round-trips to the web service, or whether to optimise a bit by sending all the data through at once, and perhaps batching all the records that needed to be updated. Typically, I follow the "write clean code, optimise later" train of thought, and after a few minutes of estimating volumes I decided to use the former approach, which would fit in better with the architecture of the application anyways. This decision was mainly based on rules of thumb that I have for how many transactions one should be able to perform through a web service in a second, as well as a healthy amount of pressure to move along and get things working :)

To my surprise, the solution turned out to be radically slower than I expected, effectively only achieving around 3 to 4 hits per second to the web service... in my experience this is a couple of orders of magnitude less than expected, so we decided to do some digging for the cause. We quickly ruled out several suspects - lack of caching on some validations, network latency, etc, and were left with two identical web services which had a large performance difference, but basically the same functionality. At this point, the penny dropped as we realised that the only difference was that our real web service was using Windows Authentication (which was necessary for integration to certain 3rd party applications). After some discussion, we decided that Windows Authentication would not be necessary for this web service, and after enabling anonymous access, performance was restored to around 1500 hits per second (and don't worry too much, the web service has application layer security in any case).

Nevertheless, this solution wasn't particularly satisfying - I was sure there had to be a "proper" solution, and I decided to dig a bit more. From the beginning, it was quite obvious that the additional overhead with Windows Authentication was the handshake that needed to happen when the web service was invoked. What I wasn't sure about was whether there was a simple way to do anything about it. I eventually stumbled upon an article on MSDN comparing the performance of web services against remoting, etc. In this article, I found an extremely simple solution - authenticated connection sharing. It seems that the HttpWebClientProtocol class - which is the base class for the code generated by Visual Studio when you import a web reference - has a property called UnsafeAuthenticatedConnectionSharing. When set to true, all calls made from that instance of the class will share their credentials, effectively doing away with multiple handshakes. I've tested the performance with this approach, and it's effectively identical to anonymous access.

There are a few things that I would love to hear from you guys:

• Do you use any of the standard authentication mechanisms with web services? Which one do you use and is there any specific reason?
• The MSDN documentation around the UnsafeAuthenticatedConnectionSharing refers specifically to NTLM. Does anyone know if this property will still work if Kerberos is used?
  

Enterprise Library 3 Released

Microsoft's Enterprise Library has been quiet for quite some time (I believe the last production release was January 2006?), but they have just released Version 3. For those that haven't yet done so, visit Microsoft's Patterns and Practices site, which not only offers best practice guidelines, but also ready-made mini-frameworks (called application blocks) that can be used in your production applications.

I haven't yet had a chance to try the new version out, but I will be doing so as soon as possible. According to the overview, the new featues include:

• Validation Application Block - which seems to standardise validation code as well as offer some basic off the shelf validators.
• Policy Injection Application Block - at first glance this seems to be Microsoft's attempt at Aspect Oriented Programming

Among the other advertised improvements seems to be a better configuration tool, along with integration into Visual Studio... cool.

Frameworks and code generation, Part II

This is the follow-up to my previous post around frameworks and code generation, where I talked about the CSLA framework.

I had read about the fact that there had been some CSLA templates around for CodeSmith, and I decided to spend some time investigating it. To my surprise, CodeSmith v4.x comes standard with CSLA templates, so there isn't even a need to download any 3rd party templates. One of the features that surprised me was that the templates have the ability to generate a base business object directly from a table definition. Although I'm not convinced that this is necessarily a clean approach, it is definitely extremely productive, in the sense that you can have a full-blown data-layer generated instantly, ready for you to expand it with validations, authorisation rules, etc.

After some customisation of the templates (we needed to modify them to make them fit some of the existing frameworks that the client was using), I was able to create a few mock screens to try out the functionality offered, and apart from a steep learning curve, it all worked as expected.

I have discussed the concept of generating the CRUD stored procedures from the table definition - if you think about it, all the necessary information is really there e.g. primary keys, identity fields, indexes, etc. I decided to have a quick look at what CodeSmith could do for me in this regard, and I was pleasantly surprised to find that there was an existing template for generating all of stored procedures I needed (albeit some minor customising was necessary, to do with SP prefixes, single name / plurals, etc).

So far, my experience with code generation has been a good one. I have only spent a few days, and most of the time was spent around customising the CSLA templates - something that most people probably wouldn't need to do. I have come to realise that it not only provides huge productivity benefits, it also helps enforce standards, which is generally a problematic area. For those that are concerned about lack of flexibility, consider the following:

• Generally, there are ways and means to extend generated code - e.g. for the CSLA code I am currently generating a base class using CodeSmith and then inheriting / extending this base class with my own code. This is an attempt at "best of both worlds" - I can re-generate the base class without fear of destroying my business logic.
• You can always change the templates or choose to make an exception. However:
• Sometimes certain enforced constraints can be good. In truth, we are often given way too much freedom to decide how to accomplish something. From experience, I would say that situations where a developer has to choose between many options are one of the least productive moments in development. The trick is to find good compromises.

Frameworks and code generation, Part I

Recently, I started consulting at a client that I used to work for a few years ago. This client is looking to develop a new product line, and to promote the products as services on the Internet (known as Software as a Service or SaaS - a topic that deserves its own post(s)). There are so many new technologies and concepts in play that the initiative could be called a "greenfields" project.

One of the main objectives of the client is to develop products using a well thought out, easy to maintain, clean architecture. At the same time, the client would also like their product to present good value for money to the customers, so they are self-conscious about over-spending on design and development.

This is quite an interesting challenge, even though it is not unique in any way (all clients would like low costs and quality). What interests me, however, is that there is a great opportunity here to introduce certain technologies to help out.

For as long as I can remember, I have been trying to figure out a satisfactory way to develop my business objects. Along the way, I have come across many design questions (e.g. do we create factories to handle object instantiation, or do we just call the constructors directly?), and came up with certain conventions, certain "standards" and certain unwritten rules. All of these things can collectively be called an "architecture" for business objects. Whilst quite flexible and productive, this architecture was limited in many ways:

• Nobody else knew about its existence. This means that collaborating with other developers generally involved either leaving them to do things their own way (which was generally at least slightly different to mine), or several hours of convincing and later on tutoring on how the code was supposed to fit together.
• The architecture was constantly changing, as I was making up my mind about how things should work.
  
• There was a fair amount of "cut-and-paste reuse" going on (which is very bad).
• Although catering for my needs quite well, the scope of the architecture was limited.

"Better than nothing, but there has to be something better out there..." - I always thought. One day I ran across a framework called CSLA.Net (Component-based Scalable Layared Architecture - Wikipedia entry, CSLA.Net Homepage), had a look at what it offered... and was seriously impressed. On paper, it promised the following (shameless semi-quotation here):

• A proper object oriented model
• Easy adoption of the architecture
• High scalability
• High performance
• N-level undo per object
• Management of validation rules
• Management of authorisation rules
• Support for different UIs based on same objects
• Support for data binding in Windows and Web Forms
• Support for transactions
  
• Simplification of issues like serialisation, remoting and reflection.
• Support from Microsoft tools, such as IntelliSense

That's quite a hefty list - it offers far more than my own architecture attempts ever did. Even better, it comes as a framework, the main difference being that a framework codifies an architecture (another shameless quote). This means that a certain amount of constraints are introduced, guiding and limiting developers towards a suggested solution. The framework has also been around since the VB 5.0 days, so it is very mature and unlikely to change, which is a desirable characteristic for those of us who don't want to spend their time upgrading their entire codebase every couple of months.

I will go into more detail around CSLA in another post - suffice to say that I have now worked with it for a little while and I'm still sufficiently impressed. One of the points that I'd like to get across is the benefits of adopting a mature framework (a lesson which the Java community seems to have learned a long time ago). So far, I have only hinted at the role of code generation in all this (which I'm covering in Part II). Basically, with so many new concepts and technologies, we knew we were in for a bit of a learning curve, as well as the related time-costs for this initiative. This meant that we needed to find a way to accelerate development somehow, and code generation holds that promise (it also has other benefits). Code generation isn't a new concept, and I have used it quite extensively in the past for specific tasks (e.g. automatically generating object wrappers for fixed-length string based mainframe calls), however it never suited my architecture due to the fact that it was constantly changing.

For those that have some spare time, I thoroughly recommend the following videos where the creator of the framework is interviewed and takes a walk through the framework: Interview Part I, Interview Part II.