The OASIS technical committee drafting up a specification for the asynchronous service access protocol (ASAP) is mulling whether to rewrite its code to accommodate the wireless device community, or to press on and revamp the draft later.
ASAP is an amendment to the simple object access protocol (SOAP), that brings into account the waiting times of more than a minute in business processes that happen when humans enter the equation. For the past month-and-a-half, a technical committee has been ironing out details of the protocol so a draft (version 1.0) could be released in December.
With the specification, officials say they will be able to incorporate it with OASIS’ ebXML message services and Web services reliable messaging specifications to ensure transactions are handled accurately.
The specification itself will be an essential tool for both communities — the wireless communications service providers and enterprise software companies — since the OASIS specification lets users monitor and control asynchronous data flow.
The spec can be used for a variety of applications, from extra-large data queries to daisy-chained Web services
“The technology for identity management is morphing and ASAP is such a neat technology that will help us,” said Gavenraj Sodhi, eTrust product manager at Computer Associates . “In terms of additional code that is to be written, we estimate that we will be plugging in the ASAP component within the SOAP messages that are being passed with others, like SAML and SPML, in the header and body of the message, carrying the information from one Web services instance to another Web services instance.”
But the most tangible benefit from ASAP comes from the manual processes in Web services — i.e., humans.
In today’s Web services environment, a user making a query that involves a higher-up’s approval will get a timeout error if that higher-up doesn’t respond in time. With ASAP, the business process can proceed apace, even if the human element creates delays.
“That allows a breakthrough in getting small business partners integrated or even large companies with a lot of manual processes left unautomated, to get everything up and running, so you’re not held captive by the lowest common denominator,” said Jeffrey Ricker, OASIS ASAP technical committee chair.
For wireless providers, an ASAP standard means its customers won’t have to labor through a “can not connect” message; instead, they’ll get something like a “please hold” prompt that connects the two users as soon as the wireless user gets in signal range.
At the heart of the matter is the many features found in the current version of the draft, which places a lot of emphasis on the enterprise and is too bulky for wireless communications — features that wireless phones likely won’t ever need. Ricker said the ASAP specification is written with every feature as a “must-have,” as the protocol within an enterprise isn’t hampered by size.
“What is the minimum requirement necessary for those ‘thin’ devices and they’ve raised some seemingly valid issues that I’m glad I know about now,” Ricker said. “When you get into wireless, they’re ‘should-haves’ or even ‘could-haves.’ In fact, in thin wireless devices, they’re just overhead that you can’t afford to have. We’re going through the painful process of ‘okay, do we really have to have that to make asynchronous work?’ ”
Right now, a debate is brewing whether to: release the draft as it stands in December and overhaul the code in the future to accommodate the wireless community; or to delay release of the draft right now so that when it does come out developers won’t have to deal with a significantly revised specification. Ricker said the latter option would only delay ASAP’s release by a month.
Ricker said the technical committee will review the options and make a decision in the next week or so, but doesn’t expect any problems regardless of the outcome.
“Luckily we have some really, really good engineers on the committee,” he said.
