In retrospect, Vazquez says going the atomic route is the best option, even though initial development takes longer because
of the time it takes to break down the functions into their basic components. Doing so lets developers create the most reusable
components, enabling them to then build up aggregate and composite components easily when it’s clear that entire sequences
of services are reusable.
By comparison, Vazquez recalls some early Web services that were so specific to their customers that no one else could use
them. “They’re technically Web services ... but they’re really just applications,” he says.
For messaging among services, SBS relies on a WSM (Web services manager) based on the X-broker platform from Infravio, which
handles the atomic and aggregate services and also provides a Web services registry.
SBS encapsulates its mainframe applications as “virtual services” within EJB wrappers that expose the functionality of the
applications using SOAP, WSDL, and XML schema. This presentation meets two needs: It keeps the EJBs’ internal business logic
private while also offering trading partners a standards-based approach to consuming the service, Vazquez says.
The system supports several data exchange standards, since SBS service providers and customers use a wide range of technologies.
Flat-file text and basic XML are the most common choices.
“We are leveraging specific XML standards for specific types of domains or transactions, such as TML, eTom, ngOSS, and others
developed by telecom industry consortia,” Vazquez says. “The challenge here, as in all standards, is the rate of adoption
among trading partners.”
In the telecom industry, Vazquez explains, adoption of such specific extensions to XML is widespread because customer data
and voice communications typically traverse multiple carrier networks and service providers. “But we haven’t done much in
terms of defining standard enterprise XML schema,” he adds, explaining that the multitude of functional and customer differences
make development of such XML schema standards too unwieldy.
Standards and practices
Although SBS has “a world-class IT services R&D group that actively researches and monitors emerging standards,” Vazquez notes,
“in some cases we simply choose to hold our integration vendor accountable for keeping us interoperable.” The reason is complexity:
As more and more WS-* standards are proposed or approved, organizations are faced with increasing development burdens, as
well as greater risk of incompatibility with external users.
For example, SBS uses WSDL 1.1 because that’s what the Infravio platform supports, and Infravio supports it rather than WSDL
2.0 because “that’s what the WS-I organization has done the most compatibility testing with,” Vazquez says. “The only standards
that we are really focusing on today are SOAP, WSDL, WS-Interoperability, and WS-Security,” he adds, explaining that those
are widely applicable and adopted technologies.
Because vendors interpret standards differently and because over time vendors will likely diverge on which standards they
support, Vazquez expects that it will become more difficult to maintain interoperability between trading partners, resulting
in a more conservative approach to the adoption of standards. When necessary, he says, SBS will create multiple versions of
services, each of which supports distinct standards, rather than trying to develop a single service that can support multiple
standards or variations. Otherwise, he says, the benefits of a component-based Web services platform will be negated by the
complexity of ensuring interoperability across so many technology variations. Similarly, to keep its development efforts manageable,
SBS tries to develop its Web services in Java and its wrappers to legacy systems in EJB, to maintain J2W (Java to Windows)
compliance.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
