SOFTware is HARD

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 now

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