Web services

learningsnortΑσφάλεια

3 Νοε 2013 (πριν από 3 χρόνια και 5 μήνες)

55 εμφανίσεις

Web Services


An Introduction

Copyright © 2013 Curt Hill

Introduction


Two computers may communicate
over the Internet using Web
Services


Typically uses HTTP

Copyright © 2013 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 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 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 reverse these steps

Copyright © 2013 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 Curt Hill

Roles


There are three roles needed to
make web services function


Service providers


Service requestors


Service directory or registry

Copyright © 2013 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 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 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 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 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 Curt Hill

Web Services

Copyright © 2013 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 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 Curt Hill

WSDL/SOAP

Copyright © 2013 Curt Hill

Alternatives

Copyright © 2013 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


However, similar capabilities can
also be handled in a RESTful fashion

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 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 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 Curt Hill