By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
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.
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.