Introducing SOAP

SOAP or Simple Object Access Protocol has become a standard mechanism in the world of Web Services. Now what exactly does this mean? And how can I make use of it inside Acrobat?

The definition given by the governing standards body W3C (World Wide Web Consortium) is:

‘SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.

SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.’

This is quite a mouthful, but essentially means that SOAP is a way for two computer programs to talk to each other using XML as the language and HTTP as the transport layer.

These two programs can be on the same network or across the other side of the planet using different hardware, software and operating systems. They can communicate because they have a common language: SOAP.

Before SOAP came on the scene there were several large vendors each with their own proprietary protocols (CORBA, RMI, COM/DCOM) and toolsets this made it very difficult to implement systems when the two systems didn’t talk the same language. SOAP promises to make these complications a thing of the past.

Now that we have a little bit better understanding of what SOAP is, the next question is how is it useful to me?

Illustrating The Point

Let’s say for example that you have a customer who wants to purchase some rare coins from your website. Since these coins are hard to find you don’t keep them in stock, instead you have a supplier that you purchase them from.

Your potential customer browses your list of coins making selections and adding them to their online shopping basket. Once they have finished browsing they want to purchase their selections and proceed to the checkout.

At the checkout page they discover that the coins that they have selected aren’t in stock and since your web site isn’t setup to automatically find available stock you aren’t able to inform the customer of the expected delivery dates.

Rather than lose a potential sale, you decide to investigate a better way to do business.

This is where Web Services & SOAP steps in. Imagine instead that your web server was able to talk to the computer of your supplier(s) and find out what stock they have and the exact delivery details, also imagine that this could be done on demand and in real-time.

All that’s required to make this happen is for the supplier(s) to create a web service for their distributors (namely your web site) that let’s you find out what stock they have and also when it can be delivered.

In the above picture the supplier’s web service is asked about a product’s availability, delivery and exact price, it returns this information in the same structured way as it was asked for, in XML.

Your web site is now able to immediately inform the customer what is available, how much it will cost and when they can expect delivery.

Acrobat And SOAP

Right about now your probably wondering how is Acrobat involved in this loop? Well it turns out that Acrobat version 6 now supports SOAP through Javascript.

This means that you can build fully interactive and graphically designed PDF documents that have built in smarts for talking to Web Services. This is great since you can combine everything that’s great about PDF with the ability to do real business with Web Services.

To really illustrate how this works I’ve created a PDF form with two examples to demonstrate how to make use of web services/SOAP. The first free web service allows you to convert between different currencies for any currency in the world and the second web service gives you the postcode for any australian city name.

There are several things going on in the background after you press the ‘GO’ button. The first thing to happen is that Javascript is called upon to create a connection between the PDF form and the Web Service. This connection is made using SOAP.

This connection is referred to as an End Point connection and generally requires a URI (Uniform Resource Indentifier). At the other end of the connection is the Web Services Definition Language (WSDL) file for the web service. This file describes the parameters and responses the web service requires and allows other users to know how to operate the web service.

After a connection has been made between Acrobat and the Web Service a Javascript Object is created representing the web service, this object can then be used to pass information to the web service in the hope it will return the information we are chasing.

The Process

As the diagram below illustrates the following five steps are happening:

  1. Connection Object created between Acrobat and the Web Service
  2. Web Service Functions called
  3. User entered data taken from Form text fields and wrapped as XML fragments
  4. Web Service process request and returns response wrapped in XML
  5. Acrobat automatically formats the raw XML data in human readable format

The potential for Web Services & SOAP to really help businesses communicate is enormous. Couple this with the platform independance, stable and secure format that we have grown to known from PDF and it’s a perfect match.

You May Also Like

About the Author: Dave Wraight

Leave a Reply