Message Oriented Middleware

In an enterprise software setting several different databases applications might need to invoke each others functionality.
For example, you might have enterprise resource planning (ERP), supply chain management (SCM), and customer relationship management (CRM) software and they might each make use of methods or data from the other.
The process of integrating such business software components is called Enterprise Application Integration (EAI).
A common idea in such integration is to have software components from one application call methods in another application using some kind of Remote Procedure Call (RPC) using a technology like CORBA or Java RMI.
The problem with this approach is that it is synchronous in that it requires one application to wait for a response from the other.
Another approach is to use Message Oriented Middleware. The calling application sends a message about an event, but does not wait for a response before continuing.
As an example, one application might send a purchase order to another application, but does not wait for a response.

Web Services

Besides needing to integrate applications within a company, many modern companies need to be able to exchange information and collaborate between companies.
This requires business-to-business (B2B) integration technologies.
A web service is a self-describing software component, which can be published, discovered, and invoked through the web.
Web services are a popular approach to B2B integration.
One technique for developing web services is to use the two XML languages: WSDL (for service discovery) and SOAP (for message exchange).
Another approach is to use a REST service.

SOAP

SOAP originally stood for "Simple Object Access Protocol".
It is a W3C spec developed in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein based on the earlier XML-RPC protocol.
SOAP 1.2 from 2007 is the most recent version of SOAP.
It no longer refers to this acronym.
As a messaging framework the design goals of SOAP were that it be:
1. extensible (can add new features)
2. protocol neutral (works over HTTP, and other application layer protocols)
3. language independent (can be used with different programming languages and architectures)
The above goals tend to make it so that SOAP, although versatile, is very verbose.

SOAP Example

A typical soap message consists of an envelope containing an optional header and a required body.
The header contains application-specific information (for security or transaction management).
The body contains an XML-encode payload which might be for either a MOM-style or RPC-style interaction.
Below is an example SOAP message to get a stock quote from http://www.webserviceX.NET for the stock with ticker symbol T (AT&T).

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 
<soap:Body>
<GetQuote xmlns="http://www.webserviceX.NET/"> 
<symbol>T</symbol>
</GetQuote>
</soap:Body>
</soap:Envelope>

WSDL Example

To find out what services are available at http://www.webserviceX.NET/, we might go to the url: http://www.webserviceX.NET/?WSDL and receive a WSDL message describing this service.
WSDL (Web Service Description Language) is an XML language developed by IBM, Microsoft, and Ariba in 2000.
The most recent version is W3C WSDL 2.0 from 2007.
A WSDL service is represented as a definitions tag which contains a set of port types that further specify a set of abstract operations.
Each operation has an input message (which could be a SOAP message) and an optional output message.
Each message specifies its attributes and their types using XML Schema.
Port types can be mapped to an implementation by specifying the URL of the implementation.

Below is an example partial WSDL document:

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
targetNamespace="http://www.webserviceX.NET/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" 
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" 
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:tns="http://www.webserviceX.NET/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"> 

<wsdl:types>
    <s:schema targetNamespace="http://www.webserviceX.NET/" 
        elementFormDefault="qualified">
    <s:element name="GetQuote">
        <s:complexType>
        <s:sequence>
        <s:element type="s:string" name="symbol"
            maxOccurs="1" minOccurs="0"/></s:sequence>
        </s:complexType>
    </s:element>
    <s:element name="GetQuoteResponse">
        <s:complexType>
        <s:sequence>
        <s:element type="s:string" name="GetQuoteResult" maxOccurs="1" minOccurs="0"/>
        </s:sequence>
        </s:complexType>
    </s:element>
    <s:element type="s:string" name="string" nillable="true"/> 
    </s:schema>
</wsdl:types>
...
<wsdl:message name="GetQuoteSoapIn">
  <wsdl:part name="parameters" element="tns:GetQuote"/>
</wsdl:message>
<wsdl:message name="GetQuoteSoapOut">
    <wsdl:part name="parameters" element="tns:GetQuoteResponse"/>
</wsdl:message>
<wsdl:message name="GetQuoteHttpGetIn">
    <wsdl:part name="symbol" type="s:string"/>
</wsdl:message>
<wsdl:message name="GetQuoteHttpGetOut">
    <wsdl:part name="Body" element="tns:string"/>
</wsdl:message>
...
<wsdl:portType name="StockQuoteSoap">
    <wsdl:operation name="GetQuote">
    <wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
        Get Stock quote for a company Symbol
    </wsdl:documentation>
    <wsdl:input message="tns:GetQuoteSoapIn"/>
    <wsdl:output message="tns:GetQuoteSoapOut"/>
    </wsdl:operation>
</wsdl:portType>
...
</wsdl:definitions>

REST

SOAP and WSDL don't really follow the KISS (Keep it Simple Stupid) paradigm for API development.
REST is another approach to web services which is arguably easier to deploy.
REST stands for Representational State Transfer. It is a technique for writing web services developed by Roy Fielding in 2000.
The idea behind REST is that most web services just provide request-reply functionality built into HTTP.
An web application state/method can be viewed as a resource. Each resource has a URL.
In addition to this basic URL, there should be a well defined set of variables which can serve as arguments to the functionality given by this resource.
These can be sent by either HTTP GET, HTTP POST, or other HTTP method.
The response from the service then says the result of carrying out the functionality.
For example, the Yioop News Service might be invoked with a line like:
```
https://www.yioop.com/s/news?f=rss&limit=20&num=30
```
The resource in this case is "http://www.yioop.com/s/news" and the arguments are (f, limit, num) which control the returned value from the resource.

In general, a web service using HTTP GET for an object "might" be given by

url/my_obj/method1?arg_1_for_method1=value_1&
    arg_2_for_method1=value_2...
url/my_obj/method2?arg_1_for_method2=value_1&
    arg_2_for_method2=value_2...
...

We used "might" above because REST is an approach to creating web services it is not a fixed specification.

RESTful API Architectural Constraints

Below are some architectural constraints that a web service should follow to be considered RESTful.

Client-server architecture - as say, given by using HTTP protocol.
Statelessness - no client context should be stored on the server between requests.
Cacheability - assume servers and client may cache responses and so a response should declare whether it is cacheable either implicitly or explicitly. For example, if you use the Post Redirect Get pattern, the Location: header in the response might indicate the response before the redirect is not cacheable, but the redirected response will be.
Layered system - should play nice with proxys and load balancers.
Code on demand - response may involve code. For example, a JSONP response gives both JSON data and a Javascript function to call with this data.
Uniform interface - the interface to the web service should satisfy:
- Resource identification in requests - URI itself says what resource the client wants. The representation of this resource for the client say as XML, JSON, HTML, etc need not be the server's internal representation.
- Self-descriptive messages - messages provide enough information to describe to a client how to process the message.
- Hypermedia as the engine of application state (HATEOS) - a client should be able to use server provided links to discover all the available resources it needs for the client's representation. (i.e., for a news feed we have links to new items and maybe links to images associated to those items.)

In-Class Exercise

You are tasked with coming up with a REST API for movie show times for the MyGreatTheatres chain of movie theatres.
Identify at least three methods that such an API might need and what arguments they should have.
Give example URLs and maybe say what the responses to those URLs would look like.
Post your solution to the Sep 16 In-Class Exercise.

Web-Services and Databases

Web Service technology might involve interactions with databases.
First, a web service can make use of a database to perform its functionality.
A database can also act as a web service provider or web service consumer.
For example, stored procedures in a DBMS can be extended with a WSDL interface and published as a web service.
Database functionality related to these procedures can be invoked then by sending the appropriate SOAP message.
A database can also act as a consumer. For example, one could imagine have stored procedures or triggers that make calls to web services.

JSON

As a conclusion to our chapter on XML databases we consider one other semi-structured data format: JSON.
Stands for Javascript Object Notation.
It is commonly used for sending data when REST is used by Javascript can immediately use the data.

Primitive types in JSON are written as you expect:

12.3  -- an example Number
"hi there" -- an example String
true -- an example Boolean, other possibility false

Arrays are written in square brackets and comma separated:
```
[1, 4, 9]
```
Objects are written in braces and the name value pair are separated by a colon:
```
{"bob": 29,  "sally" : 35}
```
JSON data can be assigned to a variable in Javascript as an object with the syntax:
```
myObj = eval( "(" + data + ")" );
```

Web Services, JSON

Outline

XML for Information Exchange