SDA ASSSIGNMENT NO 5

SUBMITTED BY: Mohsin Aslam

SECTION: BCSE 6B
REGISTRATION NO: F171BCSE186
Q: Make a Detailed note on the following points.
1. System types (Personnel systems, Embedded systems, Distributed
systems)
2. Thin Client model
3. Fat Client model
4. 3-tier middleware architecture.

Ans:
1. System Types:

 Embedded Systems:
EMBEDDED SYSTEM is a combination of computer software and hardware which is
either fixed in capability or programmable. An embedded system can be either an
independent system, or it can be a part of a large system. It is mostly designed for a
specific function or functions within a larger system. For example, a fire alarm is a
common example of an embedded system which can sense only smoke.

Example of Embedded Systems

Laser Printer

Laser Printers are using embedded systems to manage various aspect of the printing.
Apart from performing the main task of printing, it has to take user inputs, manage
communication with the computer system, to handle faults, and sense papers left on the
tray, etc.

Here, the main task of the microprocessor is to understand the text and control the
printing head in such a way that it discharges ink where it is needed.

To perform this, it needs to decode the different files given to it and understand the font
and graphics. It will consume substantial CPU time to process the data as well as it has to
take user inputs, control motors, etc.
  Distributed Systems:
A distributed system, also known as distributed computing, is a system with multiple
components located on different machines that communicate and coordinate actions in
order to appear as a single coherent system to the end-user.

The machines that are a part of a distributed system may be computers, physical
servers, virtual machines, containers, or any other node that can connect to the network,
have local memory, and communicate by passing messages.

There are two general ways that distributed systems function:

1. Each machine works toward a common goal and the end-user views results as one
cohesive unit.
2. Each machine has its own end-user and the distributed system facilitates sharing
resources or communication services.

Although distributed systems can sometimes be obscure, they usually have three primary
characteristics: all components run concurrently, there is no global clock, and all
components fail independently of each other.

Benefits and challenges of distributed systems

There are three reasons that teams generally decide to implement distributed systems:

 Horizontal Scalability—Since computing happens independently on each node, it

is easy and generally inexpensive to add additional nodes and functionality as
necessary.
 Reliability—Most distributed systems are fault-tolerant as they can be made up of
hundreds of nodes that work together. The system generally doesn’t experience
any disruptions if a single machine fails.
 Performance—Distributed systems are extremely efficient because work loads
can be broken up and sent to multiple machines.

However, distributed systems are not without challenges. Complex architectural design,
construction, and debugging processes that are required to create an effective distributed
system can be overwhelming.

Three more challenges you may encounter include:

 Scheduling—A distributed system has to decide which jobs need to run, when
they should run, and where they should run. Schedulers ultimately have
limitations, leading to underutilized hardware and unpredictable runtimes.
  Latency—The more widely your system is distributed, the more latency you can
experience with communications. This often leads to teams making tradeoffs
between availability, consistency, and latency.
 Observability—Gathering, processing, presenting, and monitoring hardware
usage metrics for large clusters is a significant challenge.

How a Distributed System Works

Hardware and software architectures are used to maintain a distributed system.

Everything must be interconnected—CPUs via the network and processes via the
communication system.

Types of distributed systems

Distributed systems generally fall into one of four different basic architecture models:

1. Client-server—Clients contact the server for data, then format it and display it to
the end-user. The end-user can also make a change from the client-side and
commit it back to the server to make it permanent.
2. Three-tier—Information about the client is stored in a middle tier rather than on
the client to simplify application deployment. This architecture model is most
common for web applications.
3. n-tier—Generally used when an application or server needs to forward requests to
additional enterprise services on the network.
4. Peer-to-peer—There are no additional machines used to provide services or
manage resources. Responsibilities are uniformly distributed among machines in
the system, known as peers, which can serve as either client or server.

Example of a Distributed System

Distributed systems have endless use cases, a few being electronic banking systems,
massive multiplayer online games, and sensor networks.

StackPath utilizes a particularly large distributed system to power its content delivery

network service. Every one of our points of presence (PoPs) has nodes that form a
worldwide distributed system. And to provide top notch content delivery, StackPath
stores the most recently and frequently requested content in edge locations closest to the
location it is being used
  Personnel systems:

Human Resources Services, Inc. designs entire personnel systems for cities and towns. In
these projects we carefully consider the specific needs of the municipality and examine
all aspects of personnel/human resource management. This would include areas such as
recruitment and selection, promotion, training and professional development, pay and
classification, EEO/affirmative action, labor relations, benefits administration, record-
keeping, worker’s compensation, civil service, disciplinary procedures, and staffing
needs which are studied in depth when designing the personnel/human resource system.
HRS also considers the municipality's form of government, its unique organizational
characteristics, and any pertinent statutory requirements as it relates to personnel and/or
human resource management.
HRS will typically conduct an overview assessment of the organization's current
personnel/human resource operations, and make necessary recommendations as to how it
should strengthen its systems.  The analysis includes a review of the personnel/human
resource department (or operations) as it currently exists; employee relations; a checklist
audit of core HR functional areas; potential areas for outsourcing and/or co-sourcing; the
HR needs of the municipality as a whole; market analysis, and recommended job
descriptions and proposed organizational structure.  HRManagement_Cycle.pdf
Our solutions take into account the unique and custom needs of our municipal clients.  In
summary the consulting services can include all or some of the following technical
assistance areas:

An analysis of the municipality's HR processes (e.g., recruitment,

Effectiveness compensation, succession planning, performance management system,
Assessment etc.) to determine their alignment with the   municipality's
daily operations and human capital strategies.

Organization An analysis of the HR organizational structure to determine its ability

Structure to deliver the HR processes and programs that support the
Review municipality's operations and human capital strategies.

HRS can assist with the development and planning of the

Development personnel/HR operations and facilitate the achievement of the HR
Planning mission through ongoing organizational, site-based, and individual
professional development services
 2. Thin Client Model:
A thin client is a computer that runs from resources stored on a central server instead of a
localized hard drive. Thin clients work by connecting remotely to a server-based
computing environment where most applications, sensitive data, and memory, are stored.

What are the benefits of a thin client?

Thin clients have a number of benefits, including:

 Reduced cost
 Increased security
 More efficient manageability
 Scalability
Thin client deployment is more cost effective than deploying regular PCs. Because so
much is centralized at the server-side, thin client computing can reduce IT support and
licensing costs.

Security can be improved through employing thin clients because the thin client itself is
restricted by the server. Thin clients cannot run unauthorized software, and data can’t be
copied or saved anywhere except for the server. System monitoring and management is
easier based on the centralized server location.

Thin clients can also be simpler to manage, since upgrades, security policies, and more
can be managed in the data center instead of on the endpoint machines. This leads to less
downtime, increasing productivity among IT staff as well as endpoint machine users.

In what ways can thin clients be used?

There are three ways a thin client can be used: shared services, desktop virtualization, or
browser based.

With shared terminal services, all users at thin client stations share a server-based
operating system and applications. Users of a shared services thin client are limited to
simple tasks on their machine like creating folders, as well as running IT-approved
applications.

Desktop virtualization, or UI processing, means that each desktop lives in a virtual

machine, which is partitioned off from other virtual machines in the server. The operating
system and applications are not shared resources, but they still physically live on a
remote server. These virtualized resources can be accessed from any device that is able to
connect to the server.

A browser-based approach to using thin clients means that an ordinary device

connected to the internet carries out its application functions within a web browser
instead of on a remote server. Data processing is done on the thin client machine, but
software and data are retrieved from the network.

3. Fat Client Model:

A fat client (sometimes called a thick client) is a networked computer with most
resources installed locally, rather than distributed over a network as is the case with a thin
client. Most PCs (personal computers), for example, are fat clients because they have
their own hard driveDVD drives, software applications and so on.

Fat clients are almost unanimously preferred by network users because they are very
customizable and the user has more control over what programs are installed and specific
system configuration. On the other hand, thin clients are more easily managed, are easier
to protect from security risks, and offer lower maintenance and licensing costs.

A system that has some components and software installed but also uses resources
distributed over a network is sometimes known as a rich client.

A fat client is often built with expensive hardware with many moving parts and should
not be placed in a hostile environment. Otherwise, the fat client may not function
optimally.

An example of a fat client is a computer that handles the majority of a complex drawing’s
editing with sophisticated, locally stored software. The system designer determines
editing or viewing access to this software.

A fat client has several advantages, including the following:

 Fewer server requirements because it does most of the application processing

 More offline work because a server connection is often not required
  Multimedia-rich application processing, such as video gaming facilitation, because
there are no increased server bandwidth requirements
 Runs more applications because many fat clients require that an operating system
reside on a local computer
 Easy network connection at no extra cost because many users have fast local PCs
 Higher server capacity because each fat client handles more processing, allowing
the server to serve more clients

4. 3-tier Middleware Architecture:

A 3-tier architecture is a type of software architecture which is composed of three “tiers”
or “layers” of logical computing. They are often used in applications as a specific type of
client-server system. 3-tier architectures provide many benefits for production and
development environments by modularizing the user interface, business logic, and data
storage layers. Doing so gives greater flexibility to development teams by allowing them
to update a specific part of an application independently of the other parts. This added
flexibility can improve overall time-to-market and decrease development cycle times by
giving development teams the ability to replace or upgrade independent tiers without
affecting the other parts of the system.

For example, the user interface of a web application could be redeveloped or modernized
without affecting the underlying functional business and data access logic underneath.
This architectural system is often ideal for embedding and integrating 3rd party software
into an existing application. This integration flexibility also makes it ideal for embedding
analytics software into pre-existing applications and is often used by embedded
analytics vendors for this reason. 3-tier architectures are often used in cloud or on-
premises based applications as well as in software-as-a-service (SaaS) applications.

What Do the 3 Tiers Mean?

 Presentation Tier- The presentation tier is the front end layer in the 3-tier system
and consists of the user interface. This user interface is often a graphical one
accessible through a web browser or web-based application and which displays
content and information useful to an end user. This tier is often built on web
technologies such as HTML5, JavaScript, CSS, or through other popular web
development frameworks, and communicates with others layers through API calls.
 Application Tier- The application tier contains the functional business logic
which drives an application’s core capabilities. It’s often written in Java, .NET, C#,
Python, C++, etc.
 Data Tier- The data tier comprises of the database/data storage system and data
access layer. Examples of such systems are MySQL, Oracle, PostgreSQL, Microsoft
SQL Server, MongoDB, etc. Data is accessed by the application layer via API calls.

Example of a 3-tier architecture: JReport.

The typical structure for a 3-tier architecture deployment would have the presentation tier
deployed to a desktop, laptop, tablet or mobile device either via a web browser or a web-
based application utilizing a web server. The underlying application tier is usually hosted
on one or more application servers, but can also be hosted in the cloud, or on a dedicated
workstation depending on the complexity and processing power needed by the
application. And the data layer would normally comprise of one or more relational
databases, big data sources, or other types of database systems hosted either on-premises
or in the cloud.

A simple example of a 3-tier architecture in action would be logging into a media account
such as Netflix and watching a video. You start by logging in either via the web or via a
mobile application. Once you’ve logged in you might access a specific video through the
Netflix interface which is the presentation tier used by you as an end user. Once you’ve
selected a video that information is passed on to the application tier which will query the
data tier to call the information or in this case a video back up to the presentation tier.
This happens every time you access a video from most media sites.

Benefits of Using a 3-Layer Architecture:

There are many benefits to using a 3-layer architecture including speed of development,
scalability, performance, and availability.  As mentioned, modularizing different tiers of
an application gives development teams the ability to develop and enhance a product with
greater speed than developing a singular code base because a specific layer can be
upgraded with minimal impact on the other layers.  It can also help improve development
efficiency by allowing teams to focus on their core competencies. Many development
teams have separate developers who specialize in front- end, server back-end, and data
back-end development, by modularizing these parts of an application you no longer have
to rely on full stack developers and can better utilize the specialties of each team.

Scalability is another great advantage of a 3-layer architecture. By separating out the

different layers you can scale each independently depending on the need at any given
time. For example, if you are receiving many web requests but not many requests which
affect your application layer, you can scale your web servers without touching your
application servers. Similarly, if you are receiving many large application requests from
only a handful of web users, you can scale out your application and data layers to meet
those requests without touch your web servers. This allows you to load balance each
layer independently, improving overall performance with minimal resources.
Additionally, the independence created from modularizing the different tiers gives you
many deployment options. For example, you may choose to have your web servers
hosted in a public or private cloud while you’re application and data layers may be hosted
onsite. Or you may have your application and data layers hosted in the cloud while your
web servers may be locally hosted, or any combination thereof.

By having disparate layers you can also increase reliability and availability by hosting
different parts of your application on different servers and utilizing cached results. With a
full stack system you have to worry about a server going down and greatly affecting
performance throughout your entire system, but with a 3-layer application, the increased
independence created when physically separating different parts of an application
minimizes performance issues when a server goes down.