SOFTware is HARD

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...

For those who are attempting to write web services in .NET to be consumed in Java. The following are things to note or watch out for: Note the WS-I guideline found here Run the WS-I tests first to ensure that the web services comply with Basic Profile 1.0. Download the "Interoperability Testing Tools 1.1" from here Refrain from having the same name for operation and parameter type (this causes Axis 1.4 to fail as it attempts to generate classes for service and parameter type. Axis will try to generate the same class for both. For example: a complex type named search will "clash" with an operation with the same name. In the WSDL: <s:complexType name="search"> will "clash" with <s:operation name="search"> ) Refrain from incorporating non-ASCII characters directly into the content of a string property (which finally gets serialized into XML). Use character encoding instead. E.g., do not use “smart quotes” directly; us...