SOFTware is HARD

In general, web applications targetted at IIS6 would be able to run in IIS7 using the Classic Pipeline. However, to take advantage of the new features and performance improvements in IIS7, the recommendation is to use the Integrated Pipeline. The differences due to the change in pipeline modes could result in: Changes in Web.Config Changes in Application Code Changes in Web.Config If the application uses HTTP modules or handlers, the following needs to be changed: system.web section is now system.webServer system.web/ httpModules is now system.webServer/ modules system.web/ httpHandlers is now system.webServer/ handlers Some minor syntactical changes to the new elements (e.g. mandatory name attribute, etc.) Changes in Application Code With the new pipeline, the Request object/ information will no longer be available through the HttpContext.Current property in Application_Start in global.asax. For completeness, there are other less used and known incompatible changes highlig...

To commit to memory, SLA 9s and acceptable unscheduled downtime: Availability % Approximate downtime/ year 90 50,000 minutes ( 800 hours ) 99 5,000 minutes ( 80 hours ) 99.9 500 minutes ( 8 hours ) 99.99 50 minutes ( 1 hour ) 99.999 5 minutes 99.9999 0.5 minutes In more details, for reference: Availability % Downtime/ year Downtime/ month* Downtime/ week 90% (“one 9”) 36.5 days 72 hours 16.8 hours 95% 18.25 days 36 hours 8.4 hours 98% 7.30 days 14.4 hours 3.36 hours 99% (“two 9s”) 3.65 days 7.20 hours 1.68 hours 99.5% 1.83 days 3.60 hours 50.4 minutes 99.8% 17.52 hours 86.23 minutes 20.16 minutes 99.9% (“three 9s”) 8.76 hours 43.2 minutes 10.1 minutes 99.95% 4.38 hours 21.56 minutes 5.04 minutes 99.99% (“four 9s”) 52.56 minutes 4.32 minutes 1.01 minutes 99.999% (“five 9s”) 5.26 minutes 25.9 seconds 6.05 seconds 99.9999% (“six 9s”) 31.5 seconds 2.59 seconds 0.605 seconds * Assume a 30-day month.

Microsoft has made the development of web services very simple for developers who use Visual Studio. Add a web service project and the basic plumbing code is generated! Many developers do not know what goes behind the hood or how to customise the generated WSDL when required. I’ve listed some salient ones that may be of help… Apply [WebService(Namespace = " http://www.johannes.org/webservice/2011/11/03/ ",Name=" ExtendingWebService ", Description=" version 1.0 ")] to the class to get these: < wsdl : definitions targetNamespace = "http://www.johannes.org/webservice/2011/11/03/" > < wsdl : documentation > version 1.0 </ wsdl : documentation > ... < wsdl : service name = "ExtendingWebService" > Apply [WebMethod(Description=" This web service is a typical one ")] to the operation to get this: < wsdl : operation name = "..." > < wsdl : documentation > This web service is a...

Application support teams who are maintaining pre-written applications may be disappointed to find that test cases have not been written prior. The recommendation is not to stop work and start writing test cases. Instead, test cases should be written incrementally . Every time you need to “touch” the application code, you should write the test cases directed at that aspect. For example: Every enhancement to the system should be supplemented with newly created test cases Every bug you attempt to fix should be supplemented with pre-fix and post-fix test cases In so doing, the risky and unstable portions of the system will be covered by test cases. At the same time, if test cases are regressed, a previously fixed bug will not resurface! See a related article

Due to the maturity of Web Services toolkits, many developers do not make the effort to understand and interpret the WSDL file. This is especially so in a code-first development environment where the WSDL is automatically generated. For those who cannot afford time to read the specifications , I’ve tried to summarise the salient concepts for both WSDL 1.1 and WSDL 2.0 in the following UML Class Diagrams. In the following diagrams, the colour annotations follows: Blue denotes type/ schema definitions Orange denotes abstract interface definitions Yellow denotes concrete definitions Green denotes message definitions WSDL 1.1 Concept Model   WSDL 2.0 Conceptual Model You should note that the main differences between 1.1 and 2.0 are: Definition is now Description PortType is now Interface Message definitions have been deprecated and so have the message bindings Port is now EndPoint Address, formerly a standalone element, is now an attribute of EndPoint Fault is ...

Here are some facts about the DataSet that ones needs to be aware of. A DataSet: is up to 30x less performant than a DataReader (refer here ) – the disparity in performance increases as more records are retrieved represents an in-memory database for the application (supports keys, relationships, validation, etc.) can be either strongly-typed or un-typed is a provider-neutral data representation is a dis-connected data object supports edits and updates as well as random access can be sorted, filtered can be very easily bound to UI controls has excellent integration with XML (serialisation to and from XML) Appropriate Use Cases DataSets are often abused and thus discouraged from use. However, they can be useful in the following scenarios: Need for a dis-connected data object that is to be batch-edited, separately updated and subsequently synchronised with the database. Although ideal for OCC or desktop client, this is also possible for a web application with a session-based DataSe...

You’ve developed the killer web service for your own consumption. You thought that sharing it with others would have been the best thing to do…You give out the WSDL and now, your service consumers are loving it! Weeks and months went by, you need to enhance the application and ripple some of the changes to your killer web service. Now what? Two types of changes There are ( backward-) compatible changes and there are incompatible changes. Examples of compatible ones (these are typically additive changes): Abstract Definitions adding new optional XML schema element or attribute declaration to an existing message definition < xsd : complexType ... > < xsd : sequence > < xsd : element ... /> < xsd : element ... /> < xsd : element ... minOccurs = "0" /> </ xsd : sequence > </ xsd : complexType > adding wildcards (i.e. xsd:any or xsd:anyAttribute) to an existing message definition < xsd : any names...