Web Services An Introduction Copyright 2013 2019 Curt
Web Services An Introduction Copyright © 2013 -2019 Curt Hill
• What is it? Web services are standardized way of B 2 B communication – Computer to computer – XML based • Uses web based applications that use a variety of standards: – – SOAP UDDI WSDL XML • Exists without much knowledge of the systems behind the firewall • Not to be confused with Amazon Web Services Copyright © 2013 -2019 Curt Hill
Differences • Not like most client/server applications – No GUI – people are not usually involved – no browser – The client and server are both programs • Two programs communicating with each other in a generalized way – Allows different programs to communicate in different ways – Minimizes custom coding Copyright © 2013 -2019 Curt Hill
History • Microsoft seems to have introduced the idea in conjunction with the. NET in 1999 –. NET was originally named Biz. Talk • 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 -2019 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 © 2013 -2019 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 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 reverses these steps Copyright © 2013 -2019 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 © 2013 -2019 Curt Hill
RPC • There are both standards for encoding Remote Procedure Call protocols in XML and JSON • This standardizes RPCs and allows them to pass a firewall • Still not that easy to setup Copyright © 2013 -2019 Curt Hill
Web Service Roles • There are three roles needed to make web services function – Service providers – Service requestors – Service directory or registry Copyright © 2013 -2019 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 © 2013 -2019 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 © 2013 -2019 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 • Forms of XML are the languages between all these exchanges Copyright © 2013 -2019 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 © 2013 -2019 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 © 2013 -2019 Curt Hill
Web Services Copyright © 2013 -2019 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 © 2013 -2019 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 Copyright © 2013 -2019 Curt Hill
WSDL/SOAP Copyright © 2013 -2019 Curt Hill
Example • Lets consider an account management system • A GUI is built that allows a new account to be created – Either by employee on someone on web • Once the data entry is done the web services portion starts Copyright © 2013 -2019 Curt Hill
Register Account • The information is bundled into a SOAP message • This SOAP message is sent to web service in an HTTP Post request • The web service unpacks the request behind a firewall – Converts to input for an application • Application process the request • If OK application creates the account – Updates the database Copyright © 2013 -2019 Curt Hill
Reply • Once database is updated, web service packs the response into a SOAP message – Contains new account number among other things • This is send to the originator • Client displays result Copyright © 2013 -2019 Curt Hill
Commentary • Started with person on a web browser • Browser communicates with a web server • Web server communicates with web services – Could be a completely different machine • The last two communicate with XML and without a browser Copyright © 2013 -2019 Curt Hill
It Gets More Complex • The above process could also be used to order a product • The first web service would then need to communicate with other web services: – Currency conversion – Credit card processing – Shipping • Shipping may also need to reorder • None of these involve a person or a browser Copyright © 2013 -2019 Curt Hill
Alternatives • 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 using UDDI – Request the service using SOAP – Understand the response of the service • However, similar capabilities can also be handled in a RESTful fashion or with JSON Copyright © 2013 -2019 Curt Hill
JSON-WSP • There are specifications (that is standardizations) that allow JSON instead of XML – These are called JSON-WSP (web service protocol) • A description language that parallels WSDL • A request that parallels SOAP • A response that parallels SOAP • A fault which handles error replies Copyright © 2013 -2019 Curt Hill
REST • REpresentational State Transfer • Often attached to a web server • Client issues a GET, PUT, POST or DELETE which are 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 -2019 Curt Hill
JSON Copyright © 2013 -2019 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 © 2013 -2019 Curt Hill
Frameworks and Protocols • There are number of frameworks • Each framework uses a particular set of protocols and interfaces with one or more programming languages • Intends to make the implementation of web services easier • There also more protocols than I have included • A few examples follow Copyright © 2013 -2019 Curt Hill
Examples • Apache Axis – Java or C++ SOAP server • g. SOAP – Software development toolkit for SOAP/XML and web services in C++ • Jersey – A RESTful Web Services in Java • Zend – Ph. P support for SOAP, JSON, REST Copyright © 2013 -2019 Curt Hill
Conclusion • The XML approach to web services generally has better standards – Not necessarily easy to automate • The RESTful approach may be easier to setup but less generalized • We will also look at SOAP Copyright © 2013 -2019 Curt Hill
- Slides: 31