Scribd
Upload
37 views50 pages

Lecture 5 DC

Uploaded by

testuser.upview
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
37 views50 pages

Lecture 5 DC

Uploaded by

testuser.upview
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 50

Distributed Computing

The Internet, Part 1: Web Services


Services
●
Services are collections of functionalities
– A bunch of functions that do related stuff
– A grouping of components
●
Have special rules to reduce network reliance
– Internal objects cannot be passed outside of the
service boundary
– Services are stand alone and aren’t incorporated as
part of other services
●
Instead other services might use your service
Problem with Services
●
Generally rely on an RPC infrastructure to
provide access
– RPC infrastructure allows for functionality usage
– Also allows for security
●
Cross platform/framework services are hard to
implement.
Web Services
●
Services, but the RPC infrastructure is the
World Wide Web.
– This just means HTTP/S.
Why do this?
●
Basically, you want a connection that is:
– Shared between all frameworks
– Easy to use
●
Otherwise why not use raw sockets?
– Able to operate on zero trust
●
This is useful when dealing with clients you don’t control
or know.
●
This has evolved over time
Raw Sockets
●
Most simple solution.
– Just jam bytecode over a TCP or UDP connection
●
Pros:
– You have total control!
– Works everywhere!
●
Cons:
– Tons of work
– You have to do everything at least once on any platform.
– No inbuilt security or permissions system
Build your own protocol
●
Build your own system for passing stuff around
a network
●
Pros:
– Can include any kind of extension you need
●
Cons:
– You gotta build it first
– On every system you want to use it on.
●
And you have to make sure your extensions work.
Just borrow someone else’s
●
Just steal another protocol and slap your
application on top
●
Pros:
– You don’t have to do any work
●
Cons:
– You’re limited to where it’s implemented
– You’re limited by the implementation
●
If it doesn’t do what you want, too bad!
Best protocol to steal
●
Should be everywhere
– All devices should already have a good means of
accessing it
●
Should be as freeform as possible
– You don’t want it interfering with your code
●
Should support a lot of extensions already
– But preferably those are optional
●
Should be easy to use!
But where could we find such a
protocol?
A Brief History Of HTTP
●
Developed in 1989 at CERN by Tim Berners-
Lee.
– He wanted to share research documents.
– Now we share dank memes.
HTTP
●
Became core of the World Wide Web in the 90s.
– This meant it was a very popular network protocol
●
Used by random flash games, but also by large
organisations for documents
– Has very good integration with modern development
tools and distributed environments
●
Is a very simple protocol at heart.
– Just sends markup text over TCP.
HTTP as the OmniProtocol
●
Everything has HTTP
●
Everything can use HTTP
●
Why not just send text over HTTP?
– URI’s can act as function or service descriptors
– Parameters can be POSTed to server
– Results can be returned as a “HTML” document.

●
However...
The Problem with Protocols
●
So we’re all using HTML
●
But…. What format do we use for returned
data?
– HTML?
●
But what if I’m not a human?
– Just raw text?
●
Now I’ve got to parse this too!
– Something Else?
●
Protocols on protocols?!
HTML
●
Structured document made of markup tags
– <head></head>
– <br />
– <h1>This is a header</h1>
●
Can be used to transfer information
– <div id=someObject>
●
Tedious, still requires some way of serializing
objects on either side.
What else can be sent over HTTP?
●
HTML is a document type suitable for Browsers.
●
There’s nothing stopping you from sending
other document types over HTTP
– Example, pictures, files, youtube…
●
So, why not just come up with a document type
that makes more sense for data?
XML
●
A 1998 rethink of the HTML standard
– Now you can define any document
– <quizzes>, <thingObject>, <html> too!
●
Allows you to use the DOM (Document Object
Model) to traverse the document much in the
same way as an object (or map/dictionary)
– document[“quiz”][“questions”][0][“answer”]
●
Returns “Damascus” or something.
XML
●
XML revolutionised web services
– Was a far easier way of transferring information
– First class data type in web languages
– Microsoft loves XML, so it is used all throughout C#
●
Loves it so much that you can turn any object into XML
by pushing it through the XmlSerializer object in System.
●
Is the foundation of most web service systems
XML example
<?xml version="1.0" standalone="yes"?>
<site>
<regions>
<africa>
<item id="item0">
<location>United States</location>
<quantity>1</quantity>
<name>duteous nine eighteen </name>
<payment>Creditcard</payment>
<description>
<parlist>
<listitem>
<text>
page rous lady idle authority capt professes stabs monster petition heave humbly removes rescue runs shady peace most piteous worser oak assembly holes patience but malice whoreson mirrors master
tenants smocks yielded <keyword> officer embrace such fears distinction attires </keyword>
</text>
</listitem>
<listitem>
<text>
shepherd noble supposed dotage humble servilius theirs venus dismal wounds gum merely raise red breaks earth god folds closet captain dying reek
</text>
</listitem>
</parlist>
</description>
<shipping>Will ship internationally, See description for charges</shipping>
<incategory category="category540"/>
<incategory category="category418"/>
<incategory category="category985"/>
<incategory category="category787"/>
<incategory category="category12"/>
XML Bad?
●
XML is verbose
– Way too verbose
– So many tags!
●
And those tags have attributes…
●
XML obfuscates structure
– Whitespace doesn’t delineate structure, tags do.
– Tags don’t make visual sense to… anyone
●
Parsers suck to write
– The format doesn’t lend itself to easy parsing
– This makes it hard to extend other languages with XML support if
they don’t already have it.
JSON
●
The no-frills 2000’s alternative to XML.
●
“Just write objects as if they are Javascript code”
●
This has a number of benefits
– Visually easy to understand (as it looks like JS code)
– Explicitly structured
– No verbosity whatsoever
●
JSON is basically the gold standard of service
data delivery in the modern age.
JSON example
JSON Good?
●
It’s shorter than XML
– And theoretically compresses better
●
It’s native to web applications
– JSON is just objects in Javascript
●
It’s really easy to write an interpreter for
– Because it’s already just Javascript
●
It’s very easy to read
– At least for developer types
JSON Bad?
●
JSON is hard to understand
– Structure is obvious, but semantics are lost
●
JSON has no attributes
– This can result in strange ways of representing data
●
JSON doesn’t use DOM
– This means that you have to have your own way of
navigating the data structure
●
You can’t just ask for all correct answers, you have to go
find them yourself.
XML or JSON?
●
Choose the best one for the job!
– Do humans need to read it? Might use XML
– SOAP? XML.
– Are you using software that has inbuilt support for
JSON? Might use that.
●
Not major differences in data size
– Usually a matter of bytes
– Both compress surprisingly well
WSDL
●
Web Services have a unique problem
– Namely, they are hosted somewhere and the code is
generally speaking hidden
– But yet, they expect you to use them
●
This is solved by a Web Service Description
Language
– WSDL is an actual specification used for SOAP based
Web Services.
– Can more generally represent a Web Service definition
WSDL Example
WSDL Example Some More
WSDL Example Even More
WSDL vs IDL
●
We’ve already discussed an Interface Definition
Language
●
WSDL is like an IDL but for the web service
●
Where it is not an actual definition, comes in the
form of API documentation.
– This happens a lot
●
A lot
SOA vs ROA
●
The last major advance in Web Services is the
distinction between
– Service Oriented Architectures (SOA) and
– Resource Oriented Architectures (ROA).
●
This is essentially the fault line between
– SOAP and
– REST
SOA
●
SOA focuses on the Service itself
– Essentially it views the Web as a point to point
protocol through which RPC/Data travels.
– Generally a single URI for each Service.
●
And by Service, we mean the full collection of objects and
functions you can use
– Generally speaking unfriendly to user interfaces
(browsers), and needs to be interpreted via another
application.
– Uses SOAP in general.
SOAP
●
Simple Object Access Protocol
●
Is an XML dialect that defines a sort of RPC tunnel
through HTTP.
– Each XML message is delivered via POST
– Returned messages are in the returned SOAP/XML
document.
●
Downsides, not at all browser understandable
– Post isn’t something you do often as a browser
– XML isn’t particularly HTML friendly
●
Unless it is HTML
SOAP example
SOAP Response Example
ROA
●
ROA are newer than SOA
– More of a Web 2.0 thing, and we’ll find out why
●
Idea is not to be a service, but a resource
– Difference is almost entirely superficial
– Services are designed for high interoperability
●
Use them in many places, not just where intended!
– Also designed in general to reflect the Web
– This means they can be websites themselves!
API
●
ROA systems generally forgo a strict WSDL in
favour of a more generic API approach
– In WSDL, you carefully define interface XML for
service interface
– In API, you give a document explaining the format
of inputs, URI locations of services, and expected
outputs.
– WSDL is designed for programs to read, API’s are
designed for humans (ergo, programmers) to
understand.
Why API?
●
APIs fit the more interoperable ROA approach
– ROA’s are supposed to be used as a resource, so
they are expected to be used by someone else for
purposes other than a specific service.
– Humans are going to be writing programs using
ROAs
– So, definitions need to be “human compatible”
REST
●
Representational State Transfer
●
Object based service access methodology
– Less a distinct language and approach to SOA,
more of a “general vibe”, or a strategy
– Attempts to better represent the Web.
– Attempts to, like the Web, be easily accessible and
useable.
REST URIs
●
REST doesn’t believe in a single service URI.
– Instead it has many URI’s representing many parts
of the resource.
– Each URI represents an individual function,
essentially
●
Ie http://thing.org/Calculator/Add and
http://thing.org/Calculator/Divide for example.
– Functions tend to follow HTTP methods…
●
Let’s take a look at those real quick
HTTP Methods
●
HTTP is not just one operation!
– Hopefully by now you know at least of GET (URI
embedding of variables) and POST (embeds variables in
request body)
●
There are in fact 5 main methods:
– GET (variable in URL ie: .../something?var=2&i=10)
– POST (variables in body)
– PUT
– PATCH
– DELETE
REST methods
●
REST methods try to follow the general idea of
HTTP methods, but with regards to data.
●
This is very useful for say, a RESTful Data Tier!
●
This is entirely optional, as is everything in
REST.
●
Let’s look at some examples...
REST Get
●
RESTful GET should “get” whatever resource
the URI indicates
– GET http://thing.org/Calculator/Settings should get
the current settings value.
– This isn’t a rule per se, but it is a good idea not to
let your GET methods change things
REST Post
●
POST Creates a new element in the resource
the URI indicates
– This can override the current entry if one so wishes.
●
But not always!
– POSTing to http://thing.org/Calculator/Settings
should let me replace the settings wholesale. Or
maybe it sets up the settings for a new calculator.
REST Put
●
PUT generally lets one update a single entry
– Or, alternatively it creates one if it doesn’t already
exist.
– Basically assume the same as POST under most
circumstances
REST Patch
●
PATCH lets you update a specific item in the
resource
– Does not create it if it does not exist, that’s an error.
– If you’re using a Replace to Update sort of
approach, may not be different to POST
REST Delete
●
DELETE… deletes stuff
– It’s pretty simple honestly
The Minimum REST
●
GET to get stuff
●
POST to create/update/replace stuff
●
DELETE to delete stuff?
– You could POST to a delete function, and it would
delete the matching item
– So you don’t actually need DELETE
REST as webpages
●
GET and POST are basic functions used by
most web pages
– And are the core functions of a RESTful interface
●
This means that REST systems can be hybrid
Webpage/Web Service systems
– A web page for GET, uses POST via web forms to
change state of the system
– Web page as a basic interface!
– What if the service returns bits of web pages...?
Next Week
●
Javascript
– The good
– The bad
– The very insecure
– We’re basically going to focus on history and how to
use it.
– Also AJAX.
●
No not spray and wipe.

You might also like