Web Services Is this the future of web based software development?
Introducing Web Services The growth of the web proves the effectiveness of using simple protocols over the Internet as the basis for a large number of services and applications, using (typically) the HTTP request reply protocol However, the use of a graphical browser can restrict the potential scope of applications Web services return to the model favoured by clientserver, that is: application specific clients interacting with a service via a functionally specialized interface (over the Internet)
Enhanced Web Servers? The provision of web services as an addition to web servers is based on the ability to use an HTTP request to cause the execution of a program However, web services need not be part of web servers and they can exist separate to any existing web server infrastructure
XML and SOAP XML is the preferred external data representation technology, with marshalled data also expressed as an XML document SOAP stands for the Simple Object Access Protocol SOAP (as defined by W3C) specifies rules for using XML to package messages when (among other things) supporting request reply protocols
Web Services Infrastructure Applications Directory service Security Choreography Web Services Service descriptions (in WSDL) SOAP URIs (URLs or URNs) XML HTTP, SMTP or other transport
Service Descriptions A web service generally provides a service description an interface definition and other information (such as the server's URL) Web service descriptions can be defined in WSDL (Web Services Description Language) Other common middleware includes web services naming and directory services
More on Web Services A web service interface consists of a collection of operations that can be used by a client over the Internet The key characteristic of most web services is that they can process XML formatted SOAP messages Many well known commercial web servers (Amazon, Yahoo, Google and ebay) offer web service interfaces that allow clients to manipulate their web resources
Web Services Combinations flight booking a flight bookingb Client Travel Agent Service hire car booking a hotel bookinga hotel bookingb hire car booking b
Communication Patterns Two alternative communication patterns are available in web services 1 the asynchronous exchange of documents, where performance is not an issue 2 the (time bound) synchronous exchange of documents, supported by an appropriate request reply protocol In general, either pattern (or combination of patterns) are used in practice An event style pattern can also be used
Communications and SOAP To allow for a variety of patterns of communication, the SOAP technologies are based on the packaging of single one way messages SOAP supports request reply interactions by using parts of single messages and specifying how to represent operations, their arguments and any results (replies)
Programming Models Web services are independent of any particular programming paradigm Unlike the distributed object model, remote objects cannot be instantiated, as a web service merely consists of a single remote object (so, garbage collection is not needed, nor are remote object references) There are alternatives to SOAP, with REST the most talked about technology
REST (Representational State Transfer) REST advocates web services with interfaces that have very little variety in their interface REST uses a constrained style based (only) on the use of URLs and the GET, PUT, DELETE and POST methods of HTTP The emphasis is on the manipulation of data resources rather than on interacting with interfaces The entire state of a resource is provided to the client, as opposed to SOAP's interface to operations
SOAP vs. REST Amazon provides both REST and SOAP interfaces to developers In 2004, statistics indicated that 80% of all requests made of Amazon's web services were via the REST interface, with only 20% via SOAP XML RPC is also an option (it is a cut down versions of SOAP) Despite this, SOAP is regarded as the market leader (for instance, Google offers only a SOAP interface) The debate rages as to what's the "best way" to build web services
Representation of Messages Both SOAP and the data it carries are represented in XML There is no limit on the potential richness and complexity of documents formatted in XML, but there could be a problem in interpreting those documents/messages that become unduly complex
Web Services in Action Each web service has a URI which is used by clients to refer to it (which is known as the "service reference") Web services may run continuously or they may be activated on demand The URL is a persistent reference it will continue to refer to the service for as long as that server exists
Transparency A major task of many middleware platforms is to protect the programmer from the details of data representation and marshalling Another task is making remote invocations look like local ones None of these things are provided as a part of an infrastructure or middleware platform for web services (Luckily) the details of SOAP and XML are generally hidden by a local API in a programming language (such as Java, Perl, Python or C++)
SOAP Designed to enable both client server and asynchronous communications XML is used to represent the contents of request and reply messages, as well as a scheme for the communication of documents Originally, SOAP was built on top of HTTP, but can work with SMTP, TCP, UDP and other protocols SOAP is an extension of XML RPCs
Initial SOAP Specification States how XML is to be used to represent messages Details how messages can be combined to form request reply patterns Provides rules to state how recipients should process the XML they receive Shows how HTTP and SMTP can be used to carry SOAP messages
Client Server SOAP To support client server communication, SOAP specifies how to use the HTTP POST method for the request message and its response for the reply message The combined use of XML and HTTP provides a standard protocol for client server communication over the Internet
SOAP Messages within Envelopes envelope header header element header element body body element body element
Details of SOAP Messages The envelope contains an optional header and body, as specified in the schema documents of the SOAP namespace When used to convey a document, the document is placed directly inside the body element, together with a reference to an XML schema detailing the service description Documents are sent either synchronously or asynchronously When used within a client server setting, the body element contains a Request or Reply message
Example Simple SOAP Request env:envelope xmlns:env =namespace URI for SOAP envelopes env:body m:exchange xmlns:m = namespace URI of the service description m:arg1 Hello m:arg2 World In this figure and the next, each XML element is represented by a box with its name in italic followed by any attributes and its content
Example Simple SOAP Reply env:envelope xmlns:env = namespace URI for SOAP envelope env:body m:exchangeresponse xmlns:m = namespace URI for the service description m:res1 m:res2 World Hello
Example HTTP POST Request (SOAP) POST /examples/stringer endpoint address Host: www.cdk4.net Content Type: application/soap+xml Action: http://www.cdk4.net/examples/stringer#exchange <env:envelope xmlns:env= namespace URI for SOAP envelope > <env:header> </env:header> <env:body> </env:body> </env:envelope> action HTTP header Soap message
Transport of SOAP Messages SOAP messages are independent of the type of transport used, as their envelopes contain no reference to the destination address The transport protocol (HTTP or whatever) specifies the destination address With the SOAP message, the Action header enables the correct destination module to be chosen without the need to inspect the entire SOAP message The HTTP content type is: application/soap+xml
SOAP Reliability Runs on top of HTTP, which runs on top of TCP TCP is not reliable, as it cannot guarantee the deliver of messages in the face of all difficulties Some work has been completed on providing reliable communication to SOAP web services (guaranteed delivery, no duplicates, message ordering maintained) Two competing specifications Ferris/Langworthy; Evans et al.
SOAP with Firewalls Web services are intended to be used by clients in one organization accessing services in another over the Internet Services running at non standard protocol ports using non standard protocols (e.g., Java RMI or CORBA) can often be disallowed by network edge firewall technology As most firewalls are configured to allow HTTP and SMTP traffic through, it makes sense to ride SOAP on top of these protocols