Distributed Computing
Distribution, Part III: Multi Tiered Architectures
Part (2)
Synchronous vs Asynchronous Methods
Synchronous vs Asynchronous Methods
C# Task and Await
ref: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/
ref: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/
Let's investugate our Async DEMO code
Identity in a Distributed App
●
How do I tell who is who in a situation where
many threads may be running?
– .NET/RMI/other: Simple! Just use the inbuilt
function state to solve that.
– But what if I want my .NET program to talk to my
RMI program?
Problems once you leave the .NET
●
As soon as you leave the frameworks, you run
into issues
– Need to be able to validate who exactly you are
– State becomes dependant on trust between
untrustworthy application parts.
●
WWW has exactly the same problem...
How I learnt how to stop worrying
about who you are and love the data
●
WWW Solution is to just stop worrying about
who is asking, or what state they are in.
– Turn the very act of contacting the service into a
service.
– This is a way of building applications without
inherent state.
– Aka; Statelessness
●
So why don’t we just borrow that?
Statelessness
●
Super popular way of building distributed apps
– Definitely not because they are usually web service
based.
●
Assume your client will supply all the info you will
need.
●
There are two ways of approaching this:
– Tell me an unguessable token that will let me know who
this is (soft statelessness)
– Tell me everything every time as I have no memory (hard
statelessness)
Statelessness
●
Requires a more data centric approach
– As state needs to be passed with the function call.
●
Requires basically no trust
– You can at worst force everyone to reauthenticate
every function call
●
Means every service must be completely self
contained
– All data it needs can be extrapolated from input
data.
Cons of Statelessness
●
You’re going to need to hold more data everywhere
– As everything needs the ability to work from no knowledge all
the time, and needs to hold all the data it may ever need to
work
●
You’re going to do a lot more distributed calls
– Caching is not possible in a stateless system
●
Or at least is inadvisable
●
You’re going to have to manage your threading without
remote callbacks
– This isn’t going to be a problem for you, but older developers
find this annoying and tricky.
Web Services Only?
●
Statelessness is not restricted to the Web
– It’s not actually enforced on the web either (SOAP)
●
It’s more of a state of mind, and an approach to
distributed application development.
●
Resolves a lot of problems with threading
– State is what messes threading up
– No state => No threading problems.
●
You can build stateless apps anywhere!
Stateless Approach
●
Message based, not Function based
– This turns everything we’ve done on it’s head.
– Means RPC isn’t the best approach
●
Though you can still do it, you’ve just gotta send a lot of
data through each way.
●
Strongly Service based design
– Assume that you will always know nothing.
– Delegate as much as you can to other services.
●
This often requires caching systems for load management.
Full Circle?
● We started last weeks at RPCs
– And now we’re saying they don’t do the job
● Why? The internet.
● Also iPhones, Android, etc…
● This does not mean a traditional RPC method is
bad per se
– In fact it’s excellent for applications that don’t cross
architecture/framework lines.
Let's DEMO a solution of Tutorial 1
Next Week
●
We investigate the dark world of Web Services
– REST
– SOAP
– JSON
– XML
– And just sending a bunch of text
●
See you then! :)
