JavaScript SOAP Client library

This library is used to establish communication with SOAP services from client-side JavaScript. Implementation of this code deals with browser cross-domain violation by means of proxying requests through a server-side code (unless service resides on the same domain as your application). Example of simple proxy is demonstrated. This library relies on jQuery platform for it's ability to perform AJAX requests, this feature can easily be replaced by either a custom code or similar functionality of other javaScript packages.

Announcement: New BETA version of SOAPClient !!!
- Updated PHP Proxy code

Introduction

How to use SOAP Client library?

SOAP Client library is a set of three core classes: SOAPClient, SOAPRequest and SOAPObject.
SOAPClient is a singleton(static) wrapper that exposes basic functionality to send a SOAPRequest to the web-service and get a response in a form of a JSON object. SOAPRequest is a class that packages all required envelope components as well as SOAPAction into one convenient package. SOAPObject is a class that is used to assemble envelope data content and represents a single SOAP node element.

So your basic usage scenario would be:

1. Assemble a SOAP Body content using SOAPObject(s)
2. Create a new SOAPRequest, setting Action and Body
3. Send SOAPRequest for processing using SOAPClient.SendRequest method
4. Process SOAP response using an asynchronous callback

Lets take a look at code example:

//First lets include three required libraries
<script language="javascript" src="jquery.js"></script>
<script language="javascript" src="jqXMLUtils.js"></script>
<script language="javascript" src="jqSOAPClient.js"></script>

JavaScript:
var soapBody = new SOAPObject("testObject"); //Create a new object that we want to send to a web service
soapBody.attr("type","test"); //Setting attributes of that object
soapBody.val("Hello World"); //Setting value of that object

//You can also use chained method that looks like this:
// var soapBody = new SOAPObject("testObject").attr("type","test").val("Hello World");

//Create a new SOAP Request
var sr = new SOAPRequest("MyAction", soapBody); //Request is now ready to be sent to a web-service

//Lets send it
SOAPClient.Proxy = "http://my-ws.com/webservice/"; //Specify web-service address (if local to your domain) or a proxy file
SOAPClient.SendRequest(sr, processResponse); //Send request to server and assign callback function

function processResponse(respObj) { //respObj is a JSON equivalent of SOAP Response XML (all namespaces are dropped)
//... do something with response
}

When to use it?

• When you already have a working web-service and have no time to write another abstraction layer to convert WS data to JSON or HTML
• When your response and request packages are small
• When you need to quickly write a lookup or search engine client for a client side

Code Features

This SOAP implementation does NOT use WSDL to resolve request and response entities which is a plus and a minus. It's a plus because there is no extra validation logic that takes time, and there is no caching of WSDL that can be quite big. It's a minus, because what you get back from the server is JSON envelope and not an Object that corresponds to WSDL, instead you have to extract the data you need by accessing Body and it's sub items directly. I also implemented only asynchronous request type, since I see very little use of using it synchronously. So let me just summarize it's features as Cons and Pros:

Pros:

• Fast, Small and Efficient
• Supports multiple namespaces
• Supports nested / complex request object parameters
• Supports SOAP Headers
• Strict object structure with separate settings for namespaces, attributes, values and nested elements
  (i.e. You can send something as complex as this - <ns0:test xmlns:ns0="uri" ns0:type="test">value</ns0:test> or
  <ns0:test xmlns:ns0="uri" ns0:type="test"><subitem>value</subitem></ns0:test>)
• Chained setting functions (i.e. var newSoapObj = new SOAPObject("test").attr("a", "hello").attr("b", "world").val("Chained"); )
• Flexible and Easy implementation that can achieve almost any complex SOAP request
• Based on well documented and proven library set such as jQuery and xmlObjectifier

Cons:

• No WSDL support (can be considered as Pros if you care about speed and memory footprint)
• Generic JSON response that gives you a whole envelope structure vs. just the object value
• Supports only Asynchronous request mode
• Requires jQuery and xmlObjectifier libraries (can be converted to non jQuery if ajax request is written manually)

Support

For all support question and suggestions please visit jQuery project page or Comments section.

Thank You,
Sam Tsvilik - Author