Course Content‎ > ‎

Section 09: Web Services

What is XML?

XML (eXtensible Markup Language) was invented for the purpose of having a standard and powerful way of describing any kind of data. XML offers a widely adopted standard way of representing text and data in a format that can be processed without much human or machine intelligence. Information formated in XML can be exchanged across platforms, languages, and applications, and can be used with a wide range of development tools and utilities.

HTML and XML - why two markup languages? Both markup languages were designed with different purposes in mind. XML is actually similar enough to HTML - they are both closely related to the SGML (Standard Generalized Markup Language) markup definition language that has been an ISO standard since 1986. SGML is an early attempt to combine the metadata (data about the data!) with the data and was used primarily in large document management systems. Because SGML is a very complex language, it has limited mass appeal and we will have no further need for it in this module!

So let's deal with HTML first. HTML has been covered somewhat in earlier chapters, so you should already have a decent understanding of its structure. HTML (Hypertext Markup Language) is the most recognized application of SGML, and is devised to allow any Web browser or application which understands HTML to display information in a consistent form. A HTML document is effective when it comes to laying out and displaying data, but it is a fixed set of tags, and it does not have the flexibility to describe different document and data types. HTML, in conjunction with Cascading Style Sheets (CSS), is reasonably good at displaying data, but it is not as good as XML at transporting data that is meant to be viewed or parsed in dozens of different ways by a variety of devices. In essence, where HTML is a presentation language, we require a richer communication means, with means of exchanging information from one computer to another.

The need to extract data and put structure around information led to the creation of XML. Since it was released in 1997, XML use has been growing rapidly. There are two major fundamental differences between HTML and XML:

  • Separation of form and content - HTML mostly consists of tags defining the appearance of text; in XML the tags generally define the structure and content of the data, with actual appearance specified by a specific application or associated stylesheet.

  • XML is extensible - tags can be defined by individuals or organisations for some specific application, whereas the HTML standard tagset is defined by the World Wide Web Consortium (W3C).

XML is not intended as a replacement for HTML and both are complementary technologies. XML is a more general and better solution to the problem of sharing data on the Web than extending HTML.

What about relational databases?   Traditional databases may be well suited for data that fits into rows and columns, but cannot adequately handle rich data such as audio, video, nested data structures or complex documents, which are characteristic of typical Web content. In order to deal with XML, many traditional databases are typically retrofitted with external conversion layers that mimic XML storage by translating it between XML and some other data format. This conversion is error-prone and results in a great deal of overhead, particularly with increasing transaction rates and document complexity.

XML databases, on the other hand, store XML data natively in its structured, hierarchical form. Queries can be resolved much faster because there is no need to map the XML data tree structure to tables. This preserves the hierarchy of the data and increases performance.

However, over 90+% of all web applications use RDBMS systems for their persistence layer.  XML on the other hand, has found it's niche in a number of different areas:

  1. As a storage mechanism in certain circumstances when structures are complex
  2. As a information transfer mechanism in web services   (more on this later)
  3. Configuration files frequently use XML as any data structure can be customised to a particular application


The following is a sample section from a possible XML document, to provide an example for you at this point. It is *not* a full XML document - we will discuss the structure of XML documents shortly and you will notice that we need a few extra lines to consider it to be a full document.

<employee> <ident>3348498</ident> <name> <lastname>Peterson</lastname> <firstname>Sam</firstname> <title>Dr.</title> </name> <phonedetails> <extension>8221</extension> <companyprefix>700</companyprefix> <regionprefix>1</regionprefix> <intprefix>+353</intprefix> </phonedetails> <department> <title>Software Development</title> <depid>8</depid> </department> <location> <building>Aston Quay</building> <room>A142</room> </location> </employee>

While not necessarily the optimum structure for information such as above, it illustrates a major point of XML. The tags are defined by individuals, rather than some predefined standard structure - so we can do what we want!

There are two different kinds of information in the above example:

  • markup - such as <department> and <firstname>

  • text/character data - such as 'Peterson' and '+353'

XML documents mix markup and text together into a single file: the markup describes the structure of the document, while the text is the document's content.


Well-Formed and Valid

XML Documents must be well-formed. Firstly, this means that you must follow the rules regarding case-sensitivity and always including closing tags. Additionally, you cannot mix the order of the nested tags: the first opened element must always be the last closed element. If any of the rules for XML syntax are not followed in an XML document, the document is not well-formed. The following is an example of an XML fragment, which is not well-formed:

<tag1> <tag2> </tag1> </tag2>

And now time to get a little confusing! well-formed document is not necessarily valid . Valid XML must additionally follow the constraints set upon an XML document by its Document Type Definition or schema.  DTDs and Schemas declare all the legal elements in a document, the legal attributes those elements can have, the hierarchy, nesting and occurrence indicators for all elements.  As an example of a DTD, check out the XHTML 1.0 DTD.


Web Applications

At this point in the course, students should be familiar with the concept of web applications.  Most should, at this point, have written their own web application, integrating client, application and data storage tiers to provide a variety of functionality.

However, there are two types of web applications:

  • Presenation-oriented: A presentation-oriented web application generates interactive web pages containing various types of markup language (HTML, XML etc.) and dynamic content in response to requests.  This is the form of web application we are familiar with and we have covered practical implementations of such applications through the vast majority of this module.
  • Service-oriented: A service-oriented web application implements the endpoint of a web service.  An application based on the principals of Service Oriented Architecture (SOA) packages functionality as a collection of services, which can be used from multiple, separate systems within different business domains.  Presentation-oriented applications are often clients of service-oriented web applications.  It is this form of web application we are concerned with in this chapter.

Introduction to Web Services

Web Services, in the general meaning of the term, are services offered via the Web. In a typical Web services scenario, a business application sends a request to a service at a given URL using the SOAP protocol over HTTP. The service receives the request, processes it, and returns a response. As an example of this consider a stock quote servie, in which the request asks for the current price of a specified stock, and the response gives the stock price. This is one of the simplest forms of a Web service in that the request is filled almost immediately, with the request and response being parts of the same method call.

Another example could be a service that maps out an efficient route for the delivery of goods. In this case, a business sends a request containing the delivery destinations, which the service processes to determine the most cost-effective delivery route. The time it takes to return the response depends on the complexity of the routing, so the response will probably be sent as an operation that is seperate from the request.

Another definition of what a Web service is provided by IBM:

"A Web service is an interface that describes a collection of operations that are network accessible through standardized XML messaging. Web services fulfill a specific task or set of tasks. A Web service is described using a standard, formal XML notion calls it service description, that provides all of the details necessary to interact with the service, including message formats (that detail the operations), transport protocols and location. The nature of the interface hides the implementation details of the service so that it can be used independently of the hardware or software platform on which it is implemented and independently of the programming language in which it is written. This allows and encourages Web services based applications to be loosely coupled, component-oriented, cross-technology implementations. Web services can be used alone or in conjunction with other Web services to carry out a complex aggregation or a business transaction"

One key driver behind the rise of Web services is the continuing evolution of Business-to-Business Computing (B2B). B2B computing is about integrating the business systems of two or more companies to support cross-enterprise business processes. Online HTML-based applications are consumer-oriented (B2C) To access most online functionality, a human being needs to use a Web browser to navigate the company's site through multiple page transitions, input information using Web forms, submit them, and get results back in human-readable form. This is entirely unsuitable for Business-to-Business (B2B) services, since automating and simulating this human use is both non-ideal and error prone. The only true way to integrate applications on the Web is to use a B2B-focused solution. Web services and consumers of Web services are typically businesses, making Web services predominantly suitable for business-to-business (B2B) transactions. B2B applications have no UI because their clients are other applications.

Web services depend on the ability of parties to communicate with each other even if they are using different information systems. XML is a markup language that makes data portable and is a key technology in addressing this need. Enterprises have discovered the benefits of using XML for the integration of data both internally (for sharing data among departments) and externally (for sharing data with other enterprises). Because of this data integration ability, XML has become the underpinning for Web-related computing. Chapter 3 of this course covered XML in considerable detail, and this section assumes that you are familiar with the concepts therein.


Figure 11.0 - Web Services Architecture (ref. Wikipedia)


The diagram above shows a generic architecture for Web Services.  The core element of this relates to the communication between the service requester and the service provider.  This communication is handled via the Simple Object Access Protocol (SOAP).


Simple Object Access Protocol (SOAP)

SOAP is a simple protocol, based on the idea that at some point in a distributed architecture, you will need to exchange information. Additionally, in a system that is probably overtaxed and process-heavy, this protocol is lightweight, requiring a minimal amount of overhead. Finally, it allows all this to occur over HTTP, which allows you to get around tricky issues such as firewalls and keep away from having all sorts of sockets listening on oddly numbered ports.

SOAP relies on HTTP as a transport mechanism to send XML based messages. The messages are packed in what is called a SOAP envelop and sent to the server to process in a Request/Response fashion. SOAP unlike other protocols such as DCOM or RMI does not require strong connection between client and the server. SOAP messages are string based messages passed from the client to the server and vice versa in the form of SOAP envelopers. Unlike other protocols, which require that the applications of the same type are running on both ends, SOAP allows access to services in an alternate language/platform. SOAP enables "incompatible" systems to interoperate.


Figure 11.1. The SOAP Message Process


Some of the features of SOAP worth noting are:

  • Uses standard internet HTTP

  • Uses XML to send and receive messages

  • Platform Independent

  • Language Independent

  • A protocol for exchanging information in a decentralized and distributed environment.

A SOAP message is based on XML and contains an Envelop, a Header and a Body.

  • Envelope - The envelope represents the Message. It is used for describing the message and how to process it.

  • Header - The Header contains the features of the SOAP message

  • Body - The Body contains mandatory information for the message receiver


Figure 11.2. SOAP Message


The SOAP envelope is analogous to the envelope of an actual letter. It supplies information about the message that is being encoded in a SOAP payload, including data relating to the recipient and sender, as well as details about the message itself.

Example SOAP message for getting a Stock Quote:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema" > <SOAP-ENV:Body> <ns1:GetStockQuote xmlns:ns1="urn:xmethods-quotes"> <SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <symbol xsi:type="xsd:string">IBM</symbol> </ns1:GetStockQuote> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

The SOAP server, using the support of complex XML parsers, decodes the call and figures that you want to get a stock quote. It then quickly fetches the stock quote and sends you back a packet like so:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:GetStockQuoteResponse xmlns:m="urn:xmethods-quotes"> <Price>34.5</Price> </m:GetStockQuoteResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>  

This, after removing all the envelopes, simply tells you that the price of the IBM stock was 34.5. Most commercial servers would return a LOT more information than just this, such as what currency, last traded price etc. However, the example is displayed to show the basic structure of SOAP messages.

While we now know, what form the messages take, we still need to know how to send and receive them. As stated, we use HTTP for this purpose. We have already described HTTP earlier in this course. Essentially, we would make a HTTP request such as:

POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" ...the soap request packet here...

The SOAPAction header indicates the 'intent' of a request, and it is mandatory. Each SOAP server could have multiple functions, and it could decide to use the SoapAction header to figure out which function is being called. Also, firewalls etc. can filter content using this header. The SOAP response from the HTTP server will be as follows:

HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn ...Soap Response packet here...



Java API for XML Web Services (JAX-WS)

JAX-WS (Java API for XML Web Services) is a Java API for building Web services and clients that communicate using XML.  It is part of the Java EE platform from Sun Microsystems and is implemented as part of project Glassfish, an open source Java EE application server from Sun.   Previous to JAX-WS was JAX-RPC (Java API for XML-based RPC) but the naming (and some functionality) was changed in Java Platform Enterprise Edition 5. 

The JAX-WS enables Java technology developers to develop SOAP based interoperable and portable web services.  SOAP, as we have seen, defines the envelope structure, encoding rules and conventions for representing web service invocations and responses.  These calls and responses are transmitted as SOAP messages over HTTP.

Despite the fact that these SOAP messages can be complex, the JAX-WS hides this complexity away from the application developer.  On the server side the developer specifies the web service operations by defining methods in an interface written in the Java programming language.   The developer also codes one or more classes that implement these methods.

While in previous years JAX-WS was used to demonstrate the development of Web Services, we are going to use Apache Axis for the same purpose due to slightly better integration with Eclipse and Tomcat (both our development platforms of choice).  This results in an easier set of steps to demonstrate.


Building a Web Service using Apache Axis and Tomcat

Apache Axis is essentially a SOAP engine allowing the deployment of web services and clients.  It is open source and freely available for download.  It provides an implementation of SOAP specification as defined by the W3C.  However, in addition it provides a simple standalone server and a plugin for integrating directly with Apache Tomcat.  

 It provides a range of facilities for the deployment of web services in two principally different manners:

  • Top Down Web Service: A top down web service is one where you create the WSDL file and use this file to automatically generate the Java classes from it
  • Bottom Up Web Service: A bottom up web service is where you create a Java bean and then use a web services wizard to automatically generate the WSDL and publish the web service
Despite the fact that these SOAP messages can be complex, Axis hides this complexity away from the application developer.  To properly demonstrate web services, we are going to build a full blown web service as well as a Java application client to test this web service.


Setup

There is nothing really involved in setup that has not already previously been covered.  We will be deploying on the existing Tomcat server which was used in earlier chapters.  You can find more information on these steps under 'Installing Eclipse'.


Creating our Web Service Endpoint

All of the following steps have been demonstrated in a video, which you can find below.  
  1. Create a new dynamic web project.  Give it a name such as 'mywebservice' (although you can call it what you like).  This creates a dynamic web application structure, that you should already be familiar with from working with Java servlets and JSPs.  There is nothing new to us here.
  2. In the src directory create a new package called 'org.dcu.ws' and then create a new Java class in it called  'Calculator.java'.  Enter the code shown below.  You will see that it is a relatively simple bean with two methods sum and multiply each taking two arguments.  The idea here is that our web service will provide calculation functionality to remote applications.
  3. Right-click 'Calculator.java' and select 'Web Services -> Create Web Service'
  4. We are creating a bottom up web service, so move the slide to 'Test service' for Service Implementation and 'Start Client' for our client.  We can hit 'Next->Next' and this will allow us to test our service using the 'Web Services Explorer' which gives us a web front end to testing the methods we have made available as web services.  However, we are going to deploy our own client, so are not too concerned with this (although it is useful for viewing the SOAP packets from a learning perspective)
  5. Note: Please follow straight through to the steps on 'Creating our Client Proxy' as technically all classes are generated at once.
package org.dcu.ws; public class Calculator { public int sum(int param1, int param2) { return param1+param2; } public int multiply(int param1, int param2) { return param1*param2; } }

Source: Calculator.java 


Creating our Client Proxy

  1. Hitting 'Next' again will bring us to the option to 'Generate Proxy' and this will generate a separate set of files which will allow us to use our web service remotely.  They are designed to provide an interface for us to use the remote web service, while having it appear as though the functions are being called locally.   We can hit 'Next' or 'Finish' at this stage and our proxy classes will be generated for us in a separate project.  If you want to look at them, these files are: Calculator.java (a client interface class as opposed to our Service on the server), CalculatorProxy.java, CalculatorService.java, CalculatorServiceLocator.java, CalculatorSoapBindingStub.java.
  2. Finally, we write a short application (Test.java) which will interface with this proxy and simply call the two methods.  These methods appear to run remotely, but actually perform remote calls to our Tomcat server with all communication occuring using SOAP over HTTP.  Our application is simply a Java Application and can run on a distinct JVM and of course an entirely different machine (the whole purpose of creating web services in the first place!)

package org.dcu.ws;

public class Test {

public static void main(String[] args) {

CalculatorProxy cp = new CalculatorProxy();

try {

System.out.println("Sum = " + cp.sum(5, 8));

System.out.println("Multiple = " + cp.multiply(34,2));

} catch (Exception e) {

System.err.println("A remote exception occured");

}

}

}

Source: Test.java


The code is relatively straightforward.  The only complication is that we need to wrap our function calls in a try-catch block, as either method could result in a 'RemoteException' (for example, if the web service was offline).  Otherwise, it looks entirely as though we are executing the application locally.  

If we execute this application (after we have deployed the web service above), we will receive the following output:


Sum = 13

Multiple = 68


You have now written and deployed a web service!  On top of this, you have created and tested a web service client!  This web service you have created can now be used remotely from anywhere by other applications utilizing the proxy client files.  


Web Services Description Language (WSDL)

The previous example seems fairly straightforward, but behind the scenes considerable work has been implemented automatically - if we were to try to do this manually we would need to implement large quantities of complex code to handle the XML parsing, construction as well as the protocols for sending and receiving SOAP messages.

By generating a bottom up web service (as we did above), we are automatically generating a Web Services Description Language (WSDL) file for our web service.  The WSDL is a document written in XML, describing the following:

  • What a service does - the methods that the service provides
  • How a service is accessed - details of the data formats and protocols necessary to access a service operations
  • Where a service is located - details of the protocol specific network address, such as a URL

In our previous example, the WSDL file for our service can be found at:

http://localhost/mywebservice/services/Calculator?wsdl

This will result in the following file:

<wsdl:definitions targetNamespace="http://ws.dcu.org">
<!--
WSDL created by Apache Axis version: 1.4 Built on Apr 22, 2006 (06:55:48 PDT)
-->
<wsdl:types>
<schema elementFormDefault="qualified" targetNamespace="http://ws.dcu.org">
<element name="multiply">
<complexType>
<sequence>
<element name="param1" type="xsd:int"/>
<element name="param2" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="multiplyResponse">
<complexType>
<sequence>
<element name="multiplyReturn" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="sum">
<complexType>
<sequence>
<element name="param1" type="xsd:int"/>
<element name="param2" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="sumResponse">
<complexType>
<sequence>
<element name="sumReturn" type="xsd:int"/>
</sequence>
</complexType>
</element>
</schema>
</wsdl:types>
<wsdl:message name="sumRequest">
<wsdl:part element="impl:sum" name="parameters"> </wsdl:part>
</wsdl:message>
<wsdl:message name="sumResponse">
<wsdl:part element="impl:sumResponse" name="parameters"> </wsdl:part>
</wsdl:message>
<wsdl:message name="multiplyResponse">
<wsdl:part element="impl:multiplyResponse" name="parameters"> </wsdl:part>
</wsdl:message>
<wsdl:message name="multiplyRequest">
<wsdl:part element="impl:multiply" name="parameters"> </wsdl:part>
</wsdl:message>
<wsdl:portType name="Calculator">
<wsdl:operation name="multiply">
<wsdl:input message="impl:multiplyRequest" name="multiplyRequest"> </wsdl:input>
<wsdl:output message="impl:multiplyResponse" name="multiplyResponse"> </wsdl:output>
</wsdl:operation>
<wsdl:operation name="sum">
<wsdl:input message="impl:sumRequest" name="sumRequest"> </wsdl:input>
<wsdl:output message="impl:sumResponse" name="sumResponse"> </wsdl:output>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="CalculatorSoapBinding" type="impl:Calculator">
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="multiply">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="multiplyRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="multiplyResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="sum">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="sumRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="sumResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="CalculatorService">
<wsdl:port binding="impl:CalculatorSoapBinding" name="Calculator">
<wsdlsoap:address location="http://localhost/mywebservice/services/Calculator"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

As can be seen in the above file, the 'location', the 'what services' and the 'how' are all described in this XML document.  The formats for the requests and responses to each of the remote methods are described as well as the data types.  

You should not read into the file in much more detail than this - it is enough to have a reasonable idea of what is described in the WSDL file.  

There are a few other important points of note with regards to WSDL files:

  1. Using only a WSDL file we could generate everything in reverse (ie. a top down development).  We could equally generate all of the web services code automatically if we were to be provided with the WSDL file as a starting point.  
  2. If other developers were able to locate our WSDL file, they would be able to use the web services we have provided.  They could automatically generate any relevant code to interface with our services and start using them.
Aside Note: In case any money-focused developers are reading this, there are a number of ways of restricting and/or charging for web services (by IP, by username/password elements transmitted in SOAP packets, charging by number of requests etc.).

There are plenty of examples of WSDL documents available on the web if you are interested in looking at some.  Here is a WSDL file which I previously used in this module to describe a fax web service providing fax resources to clients.   You can see the various services made available by this 'Interfax' Company - users of their service could package data into a SOAP message and the Interfax company would process this SOAP packet, send the relevant fax complete with data to the provided phone number and return a SOAP response indicating the success of failure of the fax sending.  Hence, if I am a web-application developer who wishes to provide, in my own application, a facility to fax invoices or tax statements, I can simply use (and pay for) this web service as long as I follow the definitions in their WSDL file.  This would typically be far preferable to  spending potentially hundreds of man-hours coding my own fax functionality.

 

UDDI - Universal Description, Discovery and Integration

UDDI is an XML-based standard for describing, publishing and finding Web services.  It is an online directory that gives businesses and organisations a standard approach to describing their services, to discover other company services and to understanding the methods required to conduct business with a specific company.  This is achieved via WSDL (Web Service Description Language) which is used to describe the interfaces of the web services. 

Before UDDI, there was no Internet standard for business to reach their customers and partners with information about their products and services.  Nor was there a reasonable approach to discovering methods of how to integrate with each other's services and processes.

So how can we use it?  Let us consider for an example, that we create a web service for checking flights across multiple airlines and making reservations with these companies.  We register our service into the UDDI directory, providing the WSDL data describing our available services and how they are used.  Travel agencies could then search the UDDI directory to find out how to use our interface.  Once the interface is found, the travel agency can now communicate with our service because we have provided it a well-defined reservation interface.  

Equally, in the process, it should be noted that we are quite likely using the web service interfaces of a number of airlines in order to provide this compiled data to the travel agencies directly. 

As has been said in a number of sections throughout the module, web services are a huge topic of study for which we could write much more content.  However, for the  purposes of this module, this is all the content we will cover.

Comments