When services communicate directly, as many if not most still do, there’s no need to define the rules of engagement that enable
service intermediation. Today’s most visible exemplars of WS-Lite -- Amazon and eBay -- use Web services in a point-to-point
way. In that mode there’s not much difference between SOAP/WSDL APIs and REST APIs, so it’s not surprising that developers
who work with these platforms overwhelmingly prefer the REST flavor. But when you do need to flow your XML traffic through
intermediaries, SOAP and WSDL suddenly make a lot more sense.
Subramaniam is a pragmatist, however. Plain XML over HTTP, sans WSDL, also plays a role in RouteOne’s internal and external
affairs. Because it’s a no-brainer to put a servlet interface onto an internal legacy system and pull XML data through it,
that strategy is used where appropriate. Some of RouteOne’s external partners use the same approach, and because “they’re
making money hand over fist” doing so, Subramaniam can’t mandate otherwise. Instead, RouteOne normalizes inbound traffic to
SOAP and WSDL in order to enable its expected future use of BPEL (Business Process Execution Language) for service orchestration.
Today, partners who don’t present SOAP and WSDL interfaces are not competitively disadvantaged. But the tipping point may
not be far off.
RouteOne depends on both SAML and WS-Security, and Subramaniam wishes he could use a standard form of reliable messaging,
too. “If I don’t send a message, we are losing money,” he says. Drawing inspiration from ebXML (e-business XML) and JMS (Java
Message Service), he specified -- and is now using with partners -- a scheme that guarantees orderly and reliable delivery
of messages. But he’d rather it were otherwise and hopes that OASIS will succeed in merging the two proposals it is now hosting:
WS-Reliability and WS-ReliableMessaging. This duplication is “really, really bad,” Subramaniam says. “I wish we had a common
spec so I could dump my stuff and just use it."
Corillian: Point-to-Point Simplicity
Many service-oriented systems don’t require reliable messaging and, according to Scott Hanselman, chief architect at Corillian,
his company’s banking middleware falls into that category. Corillian’s product, called Voyager, handles services touched indirectly
by 25 percent of all users of online banking, Hanselman says. “But the only transaction they care about is the one at the
host.” So he’s not worried about the merger of WS-Reliability and WS-ReliableMessaging. Although he does make use of WS-Security,
he regards SSL as equally effective in most cases. That approach precludes routers and intermediaries, he admits, “but rarely
do I use them, because nine times out of 10 we’re doing point-to-point messaging.”
He’s also dismissive of UDDI, the much-maligned standard for publishing directories of Web services. What about the argument
that services not found in the yellow pages won’t be reused? Hanselman doesn’t buy it. Finding services isn’t really a problem
for developers, he says. Using them easily and effectively is. Imagining a fictional average developer named Mort, Hanselman
opines that SOA will be a nonstarter until we can shield Mort from XML angle brackets and X.509 certificates. To that end,
he thinks the most important standard is WSDL because it’s a tool-enabler.
Of course WSDL has earned its fair share of criticism, too. RouteOne’s Subramaniam thinks that the “goofy” complexity of WSDL
1.1 made it a ball and chain that SOA has had to drag around, and he hopes that the “much cleaner” WSDL 2.0 will lighten the
load. Perhaps, Hanselman says, but “you can’t unring the bell.” Millions of Web services transactions ride on WSDL 1.1 and
will for a long time to come. Using WSDL 1.1, Corillian was able to describe the objects, messages, and services at the core
of Voyager and to bind those descriptions to internal machinery that doesn’t speak XML. As the need arose, the company created
alternate bindings that enable customers to see the engine through a Web services lens. If WSDL 1.1 was an 80 percent solution,
Hanselman thinks, then WSDL 2.0 might be a 90 percent solution, but either can deliver crucial leverage.
Ohio State: Securing Vital Signs
The most widely adopted of the advanced Web services standards is clearly WS-Security. Beyond that it’s hard to find practitioners
who have worked with the more exotic beasts in the WS menagerie, but Furrukh Khan -- who holds joint appointments in the colleges
of engineering and medicine at the Ohio State University Medical Center and is broadly responsible for its medical IT -- tells
a fascinating story about his transition from basic to advanced Web services.
In this scenario, vital signs flowing from monitors are recorded in databases and are simultaneously delivered to smart clients
that observe, replay, analyze, and annotate the streams of data. The streams must be delivered to a lot of clients reliably,
securely, and in near real time.
A first implementation, based on Microsoft’s WSE (Web Services Extensions), made use of WS-Policy, which hasn’t yet found
a home in a standards body but likely will soon. WS-Policy was used to declare the means of authentication to back-end databases
— for example, to require X.509 certificates signed by a specified key — as well as the required payload signature and encryption.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
