Another Programming Update

MoreVisibility - July 28, 2011

It has been a very busy summer for IT departments that have integrated web services as part of their Application Program Interface (API) for business automation. Web services are designed to bridge the gap between business processes available over HTTP via standard browsers and the groups of companies that have developed business processes and APIs that are consumers of this information. For example, a search engine’s portal provides on-line reports concerning click data as well as maintenance panels for online marketing campaigns to humans via HTTP and a browser. In order to efficiently manage reports and track this data, APIs are developed to automate these human interactions with the search engines portal via leveraging their web services.

Due in part to rapid advancements in the technology supporting these channels, search engines are moving forward with so many new features such as re-marketing, mobile and video ads, that the pace of new web services is at an all time high. This means more work for the search engines to not only develop and deploy a human portal available over HTTP, but to also provide the interfaces for exchanging these new elements to their web services consumers; and attempt tokeep backward compatibility with previous releases.

Luckily, many years ago, IBM and MicroSoft teamed up to standardize how programs obtain their road map for using web services and created the Web Services Description Language, WSDL. It is an XML formatted document that describes the service being offered and its’ variables and method parameters. In theory, developers obtain the new updated WSDL and use one of the many tools that convert this XML document into source code in the form of Java, VB.Net, C#.Net, RPG or whatever language is being used by their IT department. The next step is to locate documentation and note deprecated processes and develop new logic to replace or possibly remove this logic from their API.

The challenges arise when the new web services no longer provide existing functionality, and are not backward compatible. It can be labor intensive to convert your logic to the latest version of the web services and then discover after hours of testing that it is not backward compatible. At this point, a developer has to begin lobbying the web service provider to reconsider this “fork” in their applications logic and to hopefully better understand what caused the vendor to change their logic. This process can either fall on deaf ears or be embraced and a patch released in a timely fashion. I am finding that vendors are human and may have overlooked a feature and attempt to patch quickly if resources are available and the number of complaints sufficient to warrant the work. Developers must present their detailed findings and provide ample documentation and supporting evidence to persuade the vendor to spend valuable time and resources to make the programming changes necessary to rectify. It helps if the communities of developers come to agreement when presenting their request for modification. Yes the blogs and forums are a key part to gaining a voice with the vendor and moving the modification through the process or to discuss ideas for a work around in the event the vendor is not receptive to the proposed modifications.