NEW YORK — Like the development of the Java programming language in its early days,
the Web services
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
the data, and WSDL
capabilities themselves — and give the interaction of data more meaning.
And finally, the building of UDDI
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.
