Distributed Information Systems

  • Created by: wreje035
  • Created on: 22-10-18 23:38
What is a DIS
DIS is a system that is made up of multiple components, where: some of those componenets are running on different computers. components communicate via a network. Some components act as servers, Some acting as clients
1 of 15
Why do we need DIS
Often need the same data in many locations. A DIS can centralise the data. Clients access via a network. A single source of truth. No replication.
2 of 15
Why cant all comps connect to database?
Lack of encapsulation. Security implications.
3 of 15
Potential problems with DIS
performance - quick enough? Connectivity - what if the server goes down. Solutions = Caching - client stores data that it receives so it doesnt need to contact the server again. Offline operation - client operates on local version of data - reg sync
4 of 15
Redundancy
The server is automatically replicated (pooling). Load can be balanced and more servers can be started to handle higher demand.
5 of 15
Creating a DIS
DIY, or use a DIS middleware framework.
6 of 15
Wire protocols
Defines the language that allows the client and server to hold a conversation. Can help with complex data and multiplicity. Can be stateful or stateless.
7 of 15
Stateful Protocols
Server asks client for each bit of info it needs to perform a task. Requires a semi persistent connection. Data can be simpler (context provided by convo). Both sides need to track entire convo.
8 of 15
Stateless Protocols
Client gives server all the info it needs in one single request. Doesnt require a persistent connection. Only client needs to track state - makes redundancy easier since client doesnt need to talk to specific server instance.
9 of 15
Stateless is perferred.
Stateless wire protocols are simpler to implement, reduced resource use on server, No need for persistent socket connections. Easier to scale.
10 of 15
Middleware
A framework that takes care of the DIS interactions for you. Sockets, wire protocol. Threading for multiple clients and asynchronous messages. Scaling/caching/redundancy
11 of 15
Types of middleware
Remote Procedure Call - Service provides a procedure/method - client can call that method. Client initiates the call but execution happens at the service.
12 of 15
Resource Oriented Architecture
RESTful web services. The client side API for the middleware is a stub. Stub translates domain data into wire protocol. Stub sends data to server. The server side API for the middleware is a skeleton.
13 of 15
Stub
Client side API for the middleware. Stub translates your domain data into the wire protocol. Stub sends data to the server.
14 of 15
Skeleton
Server side API for the middleware. This is how you tie your server code into the middleware. Skeleton works out what should happen in response to a new message arriving. Skeleton interacts with your service, passing in message data.
15 of 15

Other cards in this set

Card 2

Front

Why do we need DIS

Back

Often need the same data in many locations. A DIS can centralise the data. Clients access via a network. A single source of truth. No replication.

Card 3

Front

Why cant all comps connect to database?

Back

Preview of the front of card 3

Card 4

Front

Potential problems with DIS

Back

Preview of the front of card 4

Card 5

Front

Redundancy

Back

Preview of the front of card 5
View more cards

Comments

No comments have yet been made

Similar ICT resources:

See all ICT resources »See all Distributed Information Systems resources »