News Stay informed about the latest enterprise technology news and product updates.

New ASAP standard takes programming out of the picture

Asynchronous Service Access Protocol (ASAP) is a new OASIS standard that enables Web services to be used in business processes where a response to a service request might take a long time, usually because there is human intervention required. When used in conjunction with the new version of Wf-XML, ASAP allows different companies to link up their business process management systems, regardless of the BPM vendor and without additional programming. In this interview, one of the standard's creators, Keith Swenson, chief architect of Sunnyvale, Calif.-based Fujitsu Software Corp., explains what ASAP is about and how it fits in with the myriad of standards available today. Swenson and his colleagues are scheduled to demonstrate ASAP/Wf-XML interoperability today at the Brainstorm Group Business Process Management Conference in San Francisco.

Keith Swenson
Can you explain the origins of ASAP?
In the early '90s, I came to Fujitsu to [work in the area of groupware] and we ended up making a collaborative planning tool. At that time I had been working with the (Workflow Management Coalition). We recognized that systems needed to interoperate with each other. So we defined what was called Interface 4, which was a way of sending SMTP messages from workflow system to workflow system. That was demonstrated in 1996.

In 1998, we realized that if we took the same things that we're passing back and forth in CORBA [Common Object Request Broker Architecture], and we construct XML messages and pass them across HTTP, then we would be able to do the same sort of coordination across the Internet. We published this spec and called it SWAP, Simple Workflow Access Protocol. This came out about three or four months before the initial SOAP spec did. I was at Netscape at the time, but Fujitsu picked up SWAP and implemented it on a number of systems here. It's been used inside of Fujitsu to do integration across systems.

We realized that to gain the benefit of all the stuff that is going on in reliable messaging, security and all the SOAP libraries, we would want to re-host the same concepts on top of SOAP. And so that's what we did with ASAP. The ideas are six or seven years old. What we've done is bought into the whole SOAP infrastructure, so we can leverage all that good work that is being done in all the other standards bodies. What are some of the problems that ASAP solves?
It allows you to link data in a bi-directional way for two long-running processes. The escrow process is something that takes a month or two. The mortgage application process is something that can take a couple of weeks. ASAP allows you to link those two with bi-directional capabilities to update information in both directions. And you can do it without programming. There is an infinite number of ways that you could do those connections if you're a programmer, but ASAP gives you a particular way to do it without programming.


Connect competing systems ASAP

Read about the early days of the ASAP spec

You described ASAP as a "plug-and-socket" protocol. What does that mean?
Choreography standards are oriented around (the question of) how to get System A and System B to talk to each other reliably, accurately and repeatedly using XML/SOAP and having the interfaces defined with WSDL (Web Services Description Language). And (they're oriented around how to) implement these choreographies using BPEL (Business Process Execution Language), C#, C++, or whatever your favorite programming language is. This is a very good, very strong technical solution.

But in contrast, what ASAP provides is something analogous to the phone plug. As a non-technician, I don't need to know how the guts of the telephone work, and I don't need to know how the telephone system works. But I can in fact install my telephone. I can plug it in.

We foresee that System A will be designed and developed by some system developers or system integrators, but possibly may be sold as a product to a company that uses it. System B may be the same thing, again developed by programmers. But they may be sold to companies that do not have developers on staff. Systems A and B are already designed to be able to communicate, but connecting them needs to be done by somebody who is not a programmer. And so, what ASAP brings is a fixed pattern. It's a layer on top of the choreography standards. It is a particular choreography that allows this type of scenario to be hooked together.

There is an infinite number of ways that you could do those connections if you're a programmer, but ASAP gives you a particular way to do it without programming.
Keith Swenson
Chief architectFujitsu Software Corp.
Can you describe the demonstration of ASAP you're doing?
We're going to have a very simple reference standards client, which is going to invoke service instances of four different implementations of a server. Those processes will turn around and invoke another service on yet another one. The scenario is that a customer places an order from a retailer, the retailer checks their stock and then turns around and places an order from a manufacturer, and then the events turn back in the other direction. We have three vendors and two open source initiatives all demonstrating the ability to implement this protocol. Are there any competing standards in this space?
As far as I know, there is no other group attempting to standardize this. This has been the biggest frustration because everybody comes up and they say, 'Why don't you just use MQSeries (or something)?' No. This is about a particular set of SOAP calls that can be made back and forth. Sometimes we talk to the BPEL guys, and they'll say, 'Why would you want to fix this down to a single process? You could do any process.' Yes, you can do any process as long as you're a programmer.

BPEL, by the way, is a programming language, it is not a protocol. But BPEL can be used to implement protocols and it's probably a very good way to implement this protocol. What we're doing here is we're creating specific operations with specific semantics so that systems can be prebuilt with those semantics built in and then an operator can hook them up without having to do programming. So as far as I know, nobody else is working on this.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.