Web Services An Introduction Copyright © Curt Hill

Introduction Two computers may communicate over the Internet using Web Services Typically uses HTTP Several approaches: –RPC –XML based –RESTful Copyright © Curt Hill

History Microsoft seems to have introduced the idea in conjunction with the.NET in 1999 –.NET was originally named BizTalk The idea was to allow interconnection of different computers over the web –Without substantial manual intervention The issues around Remote Procedure Calls could then be disarmed Copyright © Curt Hill

Remote Procedure Call AKA remote invocation or remote method invocation Concept where a program can call a subroutine in another address space and receive results Often this other address space is actually on another machine –Both are usually connected through the internet There needs to be a mechanism that makes this relatively painless Copyright © Curt Hill

RPC Process Program calls the client stub, a local procedure Client stub packs the parameters into a message and uses the OS to send the message –Packing is called marshalling The remote system passes the incoming packets to another stub This stub unpacks the parameters Stub calls the procedure that does the work Reply reverse these steps Copyright © Curt Hill

RPC Problems Remote Procedure Calls raise security issues DCOM and CORBA are two common means to use RPC These usually have problems with a firewall or proxy server They are typically difficult to set up and not as platform independent as desired Copyright © Curt Hill

Roles There are three roles needed to make web services function –Service providers –Service requestors –Service directory or registry Copyright © Curt Hill

Service providers Correspond to the remote procedure in RPC They provide some kind of service to any requester –Example: convert one currency to another The service must have a standard description –The description is usually in Web Services Definition Language (WSDL) –Pronounced wiz dul Copyright © Curt Hill

Service requestors Clients that need a particular service They discover the availability of the service through a service directory They find how to access the service through WSDL They access the service –Often using SOAP Copyright © Curt Hill

Service directory or registry Implements UDDI –Universal Description, Discovery and Integration service Service providers register with a directory Service requestors query a directory XML is the language between all these exchanges Copyright © Curt Hill

XML XML is the generalized way to exchange information in a platform independent way Every platform will be able to read, parse and understand XML Each of these messages will be in XML –The web services request and response –The WSDL query and reply –The registration of a new service Copyright © Curt Hill

XML Web Services Instead of sending an HTTP command an XML file is sent –This details the type of request An XML file is returned describing the results This may have a state –A conversation may ensue where each request/reply depends on previous –State is inside the XML Copyright © Curt Hill

Web Services Copyright © Curt Hill

Commentary In the above picture it appears that the originator is a person operating a browser This does not have to be the case It could just as well be an application that has as part of it a browser component that sends and receives messages Copyright © Curt Hill

SOAP Simple Object Access Protocol A typical, but not only XML Web Service protocol SOAP applications typically: –Find a Web Service provider with UDDI –Parse the WSDL to find the correct way to request and receive services –Send and receive SOAP XML to obtain the services There is another presentation on SOAP and related protocols Copyright © Curt Hill

WSDL/SOAP Copyright © Curt Hill

Alternatives Copyright © Curt Hill The web services approach shown above is not the only approach It is nice in that all of these functions may be handled by program: –Discover the service –Request the service –Understand the response of the service There are some problems with this approach

XML/SOAP Problems Copyright © Curt Hill The usual criticism is that this is a cumbersome protocol –Very general but inefficient However, similar capabilities can also be handled in a RESTful fashion

REST REpresentational State Transfer Often attached to a web server –Web servers are stateless and lightweight We still transfer data from server to client, but in an easier way The servers are already present, so implementing these is somewhat easier Copyright © Curt Hill

RESTful Transfers Client issues a GET, PUT, POST or DELETE –The normal commands in HTTP REST is stateless, like HTTP –Once request and response are complete there is nothing more to do The transfer messages may be in XML/HTML or anything REST is an architecture, not a protocol Copyright © Curt Hill

RESTful Architecture A resource is the item being provided It may be: –A simple value such as a price converted to a different currency –A record such as a line of an invoice –A catalog or book It may also be in whatever format is convenient, such as XML, but also a document in any format Copyright © Curt Hill

Operations Ah CRUD! Resource operations and their HTTP commands: –Create – POST –Read – GET –Update – PUT –Delete – DELETE Now access via URL Copyright © Curt Hill

RESTful Problems Simple requests are easy to construct but complex interfaces are not SOAP is standardized but RESTful requests are not It is possible that each resource has both a RESTful and SOAP interface Copyright © Curt Hill

Application This is the key to B2B collaboration, among other things Consider the following scenario: –Warehouse processes an order –Stock item falls below reorder point –Warehouse initiates a web service –SOAP order for the item is sent –Provider processes the order and initiates shipping –Warehouse receives new stocks Copyright © Curt Hill

Mobile Apps Any web service should be convertible to a mobile app –All that is required is an HTML(5) front end Process –The front end takes information from user –Transmits to service provider –Recieves reply –Displays results Store URL, no need for app store presence Copyright © Curt Hill