Transcript Web services

Web Services
An Introduction
Copyright © 2013-2015 Curt Hill
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
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
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
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
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
Roles
• There are three roles needed to
make web services function
– Service providers
– Service requestors
– Service directory or registry
Copyright © 2013-2015 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-2015 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-2015 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 © 2013-2015 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-2015 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-2015 Curt Hill
Web Services
Copyright © 2013-2015 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-2015 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 © 2013-2015 Curt Hill
WSDL/SOAP
Copyright © 2013-2015 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
– Request the service
– Understand the response of the service
• There are some problems with this
approach
Copyright © 2013-2015 Curt Hill
XML/SOAP Problems
• 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
Copyright © 2013-2015 Curt Hill
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
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
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
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
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
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
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