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:

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

Setup

Creating our Web Service Endpoint

Demonstrating Web Services Video

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;
   }
}

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!)

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:

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:

This will result in the following file:

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.

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.