Like the development of the Java programming language in its early days, the Web services movement is traveling a “bumpy road” right now, an IBM executive said.
But that road is being paved over while Web services deployment among many businesses continues moving into production and wide use, added Mark Colan, senior evangelist with IBM’s Web Services Technology group.
“You can make a good case for using Web services if you make simple self-describing modular applications that are independent of any component model, implementation language, transport protocol, operating system and platform,” he told an audience of developers.
Colan was among a group of IBM executives, part of its traveling Developer Works conferences, that landed in New York City Tuesday. The group was chock full of tutorials as well as tips on best practices emerging among Web services standards groups.
Web services are a standardized way of integrating Web-based applications over an IP backbone, enabling applications to interface with one another — across a variety of platforms and environments.
The applications not only share data, but share data with enhanced meaning, such as supply orders, financial data and customer relationship management information without human intervention.
Colan conceded that while interoperability remains a frustrated goal of many Web services projects, various working groups and developers are making progress on common protocols that underpin Web services deployment.
Those building blocks include XML to tag data, SOAP to transfer the data, and WSDL to actually describe the Web services capabilities themselves — and give the interaction of data more meaning. And finally, the building of UDDI services, which provide directories of Web services that can be consumed by a trading partner.
“There ought to be a book on best practices in Web services, but right now, we’re seeing bits and pieces emerging,” said Colan, while noting that books about Web services are in the works. But in the meantime, he added, it doesn’t hurt to remember that simple coding across all the protocols works best.
“The key to performance has to do with how you design messages,” for example, he said. “Simpler is better. With fewer elements in a (programming) stream,” the better the performance of an application. “When you increase complexity and introduce more elements in each process, the performance of the application is affected,” as are CPUs for that matter, he added.
That’s why he urged simplicity as a keyword for developers working at each level of a Web services interface.
For example, “design XML schema first for portability, and keep the programming language neutral,” which means you have to leave your C#, Java, or other programming hats at the door when writing data descriptions, he said.
Always describe your services in WSDL, and stick with SOAP literal rather than using the SOAP Encoding method, a technique that pre-dated the ratification of WSDL, Colan continued.
That way, you’ll avoid the issues such as serialization and deserialization of null values and case sensitivy mismatches that were common with the SOAP Encoding style.
Just remember that “SOAP is, at its heart, a messaging system,” said Colan. “Type encoding is an optional part of the specification.”
Other tips and hints that he collected from programmers and interoperability groups include:
* Expose coarse grained interfaces
* Write interoperable WSDL, stick to standard XSD data types
* Avoid complex and nested method signatures and null values
* Selection and configuration of SOAP runtime is key
* Avoid using custom mappings for compression or other purposes, they introduce dependencies and software distribution effort.
Perhaps most important, he added, is to test early, often and leverage that experience.
Colan urged developers to cull bits and pieces of best practices that are emerging, as businesses adopt common programming standards in order to achieve the “write once, use everywhere” ideal that frames Web services adoption among enterprise networks.