1. Web Services An Introduction Copyright © 2013-2015 Curt Hill

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

3. 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 © 2013-2015 Curt Hill

4. 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 © 2013-2015 Curt Hill

5. 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 © 2013-2015 Curt Hill

6. 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 © 2013-2015 Curt Hill

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

8. 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 © 2013-2015 Curt Hill

9. 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 © 2013-2015 Curt Hill

10. 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 © 2013-2015 Curt Hill

11. 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 © 2013-2015 Curt Hill

12. 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 © 2013-2015 Curt Hill

13. Web Services Copyright © 2013-2015 Curt Hill

14. 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 © 2013-2015 Curt Hill

15. 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 © 2013-2015 Curt Hill

16. WSDL/SOAP Copyright © 2013-2015 Curt Hill

17. Alternatives Copyright © 2013-2015 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

18. XML/SOAP Problems Copyright © 2013-2015 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

19. 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 © 2013-2015 Curt Hill

20. 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 © 2013-2015 Curt Hill

21. 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 © 2013-2015 Curt Hill

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

23. 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 © 2013-2015 Curt Hill

24. 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 © 2013-2015 Curt Hill

25. 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 © 2013-2015 Curt Hill