Applying Semantics to XML Transfers | Beginning XML Databases (Wrox Beginning Guides)

You already know that XML documents contain data, which is the content. The contents of an XML document are the textual items contained between the element tags. So, in the following XML fragment, the name of the country (England) is the content:

   <country>  England  </country>

You also know that XML documents contain metadata. Metadata is the data describing the content. In the case of XML, metadata can implement or impose structure onto the content. In the following XML fragment, the hierarchical structure is the metadata describing the hierarchy of the regions , countries , and cities:

   <region name="  Europe  ">    <country name="  England  ">       <city>  London  </city>       <city>  Manchester  </city>    </country>    <country name="  Germany  ">       <city>  Hamburg  </city>       <city>  Frankfurt  </city>    </country> </region>

The XML fragment contains inherent metadata, which determines the following facts based on the hierarchical structure of the XML elements and their respective attributes:

London and Manchester are both cities in England.
Hamburg and Frankfurt are cities in Germany.
England and Germany are part of Europe.
All cities and both countries are all in Europe.

Once again, retrogressing to the language translation and newsfeed examples, the preceding example is completely different from those two aforementioned examples. In other words, sending straightforward XML content and metadata between computers is somewhat meaningless in relation to the context or overall meaning of the XML document. So, what is needed is something on both ends of a transfer that can interpret the context of the XML data. The context in the preceding examples would be the general topic of the XML document: language translation, a newsfeed, and cities in countries in Europe.

How can all this information be drawn together and transferred between different computers, such that the different computers can also interpret the context of these different types of data? The answer to this question is that you would have to send a message to another computer, essentially telling it what you are sending.

How can the context of an XML document transfer be determined at both end points of a transfer?

Simple Object Access Protocol

Simple Object Access Protocol (SOAP) allows for the specification of the context of data sent as messages between different computers. The different computers sending and receiving data all understand both XML and the SOAP specification you are using, and thus the context can be understood as well. Now isnt that clever!

Essentially a SOAP message or document consists of a number of things:

Envelope: This is the root node wrapper for the SOAP XML document that allows inclusion of a namespace for interpreting the SOAP namespace tags. SOAP namespace tags are contained within the XML message document.
Header: This section is optional and allows for further description of the XML data, which is contained within the SOAP body element. The SOAP header section describes the SOAP body section.
Body: This section contains the XML document data. For the previous examples, the body section would contain language translation, a newsfeed, or cities in countries in Europe.

It gets even better. SOAP is also written in XML. XML happens to be universally understood as a standard. And therefore SOAP also becomes a universally understood standard by the computers involved in a transfer of data. How does this work? The envelope of a SOAP message allows for a namespace. That namespace can contain all the definitions of the SOAP tags including the envelope, header, and body tags. So, the interpretation of the XML metadata specific for SOAP is retrieved directly over the Internet, from the World Wide Web Consortium (W3C). The SOAP specification and information about how SOAP tags are interpreted are found at www.w3.org. Thats what a namespace does. Its puts interpretation of specialized XML tags onto the Internet, and the interpretation is thus available to anyone , anywhere in the world, with any computer, and any Internet browser.

A namespace provides a set of definitions for the interpretation of specific XML tags. In other words, there is no programming needed for client or server computers in order to interpret the SOAP XML tags. That interpretation is already done for you. No complex programming is required other than the SOAP scripting, of course.

Put all these parts and pieces together and you should see that this is all very clever indeed. Its almost like the computer worlds answer to a complete theory of cosmology, melding together all of classical physics, relativity , and quantum physics. Thats quite a stretch but there might just be something to get excited about here.

Examine the region of Europe. The SOAP equivalent might look something like this:

   <?xml version="1.0"?> <SOAP:Envelope xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope"> <SOAP:Header></SOAP:Header> <SOAP:Body>    <region name="  Europe  ">       <country name="  England  ">          <city>  London  </city>          <city>  Manchester  </city>       </country>       <country name="  Germany  ">          <city>  Hamburg  </city>          <city>  Frankfurt  </city>       </country>    </region> </SOAP:Body> </SOAP:Envelope>

Figure 7-1 shows a browser-executed version of the preceding example.

Figure 7-1: Including SOAP namespace commands in an XML document

As you can see in the preceding examples, SOAP element definitions can be found at the following URL:

   http://www.w3.org/2003/05/soap-envelope

Figure 7-2 shows a partial picture of the content contained in the preceding URL.

Figure 7-2: The W3C website soap-envelope namespace definition

If we now examine the language translation example again, an equivalent SOAP message might look something like this:

   <?xml version="1.0"?> <SOAP:Envelope xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope"> <SOAP:Header></SOAP:Header> <SOAP:Body>    TranslateThisPlease { "Hello", "English", "French" } </SOAP:Body> </SOAP:Envelope>

Figure 7-3 shows a browser-executed version of the preceding example.

Figure 7-3: Calling a function in a SOAP script

The difference between the countries and cities example in relation to the language translation example, is that the former is just data, and the latter contains a function. Data is static information and a function performs some processing. Technically speaking, the preceding language translation example is incorrect as specified using SOAP because the translation function is not part of the SOAP specification on the W3C website. Here is where all this stuff gets even more interesting. What needs to be done is to provide an interpretation of the function. In other words, the function code needs to be retrieved from somewhere so that the function can be executed. The problem can be solved by using another namespace, which is specific to the function concerned :

   <?xml version="1.0"?> <SOAP:Envelope xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope"> <SOAP:Header></SOAP:Header> <SOAP:Body>    <trans:TranslateThisPlease xmlns="  http://www.translationstuff.com/soap-stuff  ">       <trans:text>Hello</trans:text>       <trans:source>English</trans:source>       <trans:target>French</trans:target>    </trans:TranslateThisPlease> </SOAP:Body> </SOAP:Envelope>

Figure 7-4 shows a browser-executed version of the preceding example. Figure 7-4 actually shows an error because the namespace declared at the URL http://www.translationstuff.com/soapstuff doesnt exist. In fact the URL itself does not exist and neither does the website. This is just for demonstration purposes.

Figure 7-4: Calling a function from a namespace

As you can see in the preceding example, the translation function is contained within a namespace other than the W3C SOAP specification namespace, at a URL that could be owned by a language translation service company. And even that can be written using XML (or at least an XML wrapper) and made and easily available over the Internet.

As you can clearly see, each and every web server can specifically define the context of data contained within an XML document from a web server. This completely eliminates the need for any type of interpretive coding on any computer. The interpretation of the coding is contained on the web server of the company providing the Web Service. No local coding to interpret the context of an XML document is required because it can all be made available over the Internet. Obviously a translation service is not free but the actual translation is coded and implemented by the company performing language translation, as a Web Service to any other Internet site that requires it.

Lets use SOAP by example to create a simple tool that sends a message to a server and returns the same message in reply. The first thing to do is to build a form in an HTML page:

   <HTML><HEAD><TITLE>Create a Message</TITLE> <SCRIPT LANGUAGE="JavaScript"> function getCountry(pCountry) { alert(pCountry.value); } </SCRIPT> </HEAD> <BODY> <FORM NAME="fCountry" ID="fCountry">    <INPUT TYPE="text" NAME="myCountry" SIZE="16" VALUE="Canada">    <INPUT TYPE="submit" VALUE="Country" onClick="getCountry(this.form.myCountry);"> </FORM> </BODY></HTML>

Figure 7-5 shows the three stages in the preceding script:

Load the page into a browser.
Click the button and get the popup (alert) window.
The URL is altered as a result of the value of the country in the form.

Figure 7-5: Create a simple message in an HTML page.

So now you know how to create a simple message. The fact is, SOAP is actually just a wrapper used to wrap messages. Those SOAP messages are sent to another computer, which simply knows how to interpret the SOAP XML structure. This script generates a SOAP structured XML document inside an HTML page through the use of JavaScript:

   <HTML><HEAD><TITLE>Create a SOAP Message</TITLE> <SCRIPT LANGUAGE="JavaScript"> function getCountry(pCountry) {    var lSOAP;    lSOAP = '<?xml version="1.0"?>\n';    lSOAP += '<SOAP:Envelope';    lSOAP += ' xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope">\n';    lSOAP += '<SOAP:Header></SOAP:Header>\n';    lSOAP += '<SOAP:Body>\n';    lSOAP += '   <c:country xmlns="http://www.somewebsite.com/soap-stuff">\n';    lSOAP += '      <c:text>' + pCountry.value + '</c:text>\n';    lSOAP += '   </c:country>\n';    lSOAP += '</SOAP:Body>\n';    lSOAP += '</SOAP:Envelope>\n';    alert(lSOAP); } </SCRIPT> </HEAD> <BODY> <FORM NAME="fCountry" ID="fCountry">    <INPUT TYPE="text" NAME="myCountry" SIZE="16" VALUE="Canada">    <INPUT TYPE="submit" VALUE="Country" onClick="getCountry(this.form.myCountry);"> </FORM> </BODY></HTML>

The result of the preceding code is as shown in Figure 7-6, again demonstrating that SOAP is simply a message, sent somewhere, in this case to a popup in the browser on the current machine.

Figure 7-6: Create a simple SOAP message in an HTML page.

And next is something equally as simple except that now rather than being sent to the popup in the current HTML page, the SOAP message is sent to an ASP server running on another computer. Also, the ASP server returns the SOAP message and it gets popped up on the screen in the HTML page. The script simply sends the SOAP message to the ASP server and back again:

   <HTML><HEAD><TITLE>Send a SOAP Message</TITLE> <SCRIPT LANGUAGE="JavaScript"> function getError(obj) {    var lstr = "Error " + obj.errorCode + " on line " + obj.line    lstr += ", position " + obj.linepos + "\n\n";    lstr += obj.reason + "\n\n";    lstr += obj.srcText + "\n\n";    alert(lstr); } function sendCountry(pCountry) {    var lSOAP = '<?xml version="1.0"?>\n';    lSOAP += '<SOAP:Envelope';    lSOAP += ' xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope">\n';    lSOAP += '<SOAP:Header></SOAP:Header>\n';    lSOAP += '<SOAP:Body>\n';    lSOAP += '   <c:country xmlns:c="http://www.oracledbaexpert.com/soap-stuff">\n';    lSOAP += '      <c:text>' + pCountry.value + '</c:text>\n';    lSOAP += '   </c:country>\n';    lSOAP += '</SOAP:Body>\n';    lSOAP += '</SOAP:Envelope>\n';    var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");    xmlDoc.async = false;    xmlDoc.loadXML(lSOAP);    if (xmlDoc.parseError.errorCode != 0) { getError(xmlDoc.parseError); }    var xmlHTTP = new ActiveXObject("Microsoft.XMLHTTP");    xmlHTTP.open("POST", "http://p1301/getSOAP.asp", false);    xmlHTTP.send(xmlDoc);    alert(xmlHTTP.responseXML.xml); } </SCRIPT> </HEAD> <BODY> <FORM NAME="fCountry" ID="fCountry">    <INPUT TYPE="text" NAME="myCountry" SIZE="16" VALUE="Canada">    <INPUT TYPE="submit" VALUE="Country"       onClick="sendCountry(this.form.myCountry);"> </FORM> </BODY></HTML>

The result, as shown in Figure 7-7, is exactly the same as in Figure 7-6 except for some slightly different formatting.

Figure 7-7: Send a simple SOAP message to ASP and back.

The ASP script for the preceding example is as follows , reading and returning the same SOAP XML message back to the calling HTML page:

   <% Response.ContentType = "text/xml" Set xmlDoc = Server.CreateObject ("Microsoft.XMLDOM") xmlDoc.load Request Response.Write xmlDoc.xml %>

The critical point to understand here is that SOAP is simply used to send messages. The formatting is understood on both ends, but still, its just a message.

What would be more useful and applicable to this particular book is using SOAP to send a message from one server to another, interpreting the SOAP structure on both ends, and returning a useful result. A number of questions could be asked at this point:

Can this technology be applied to sending XML documents between two databases? It can but the two databases used in this book both contain XML data types that helps.
Why would one need to transfer XML documents from Oracle to SQL Server, or vice versa, and send them as a SOAP message? This obviously makes this software somewhat irrelevant in the case of this book. Of course if you want to restructure the XML documents between the databases it might make sense to use SOAP. However, there are plenty of other utilities for scanning XML documents and rebuilding that XML into a different structure particularly within the XML capabilities of the databases themselves .
Is this technology actually useful in relation to database-to-database transfers of XML documents? No. Not when both databases contain XML data types. However, if you want to update one of the databases, either in relational tables or with an XML data type, you can use something like the translation function to pull something off a feed namespace. Feeds contain information such as stock quotes, weather reports , and in the case of this book population and currency exchange rate figures. This type of service is provided by passing SOAP messages to the service, which the service understands. Additionally, the feed Web Service needs something applying further meaning and structure to the message, using something like Web Service Description Language (WSDL).