goal of presentation layer

• Engineering Mathematics
• Discrete Mathematics
• Operating System
• Computer Networks
• Digital Logic and Design
• C Programming
• Data Structures
• Theory of Computation
• Compiler Design
• Computer Org and Architecture
• Computer Network Tutorial

Basics of Computer Network

• Basics of Computer Networking
• Introduction to basic Networking Terminology
• Goals of Networks
• Basic characteristics of Computer Networks
• Challenges of Computer Network
• Physical Components of Computer Network

Network Hardware and Software

• Types of Computer Networks
• LAN Full Form
• How to Set Up a LAN Network?
• MAN Full Form in Computer Networking
• MAN Full Form
• WAN Full Form
• Introduction of Internetworking
• Difference between Internet, Intranet and Extranet
• Protocol Hierarchies in Computer Network
• Network Devices (Hub, Repeater, Bridge, Switch, Router, Gateways and Brouter)
• Introduction of a Router
• Introduction of Gateways
• What is a network switch, and how does it work?

Network Topology

• Types of Network Topology
• Difference between Physical and Logical Topology
• What is OSI Model? - Layers of OSI Model
• Physical Layer in OSI Model
• Data Link Layer
• Session Layer in OSI model

Presentation Layer in OSI model

• Application Layer in OSI Model
• Protocol and Standard in Computer Networks
• Examples of Data Link Layer Protocols
• TCP/IP Model
• TCP/IP Ports and Its Applications
• What is Transmission Control Protocol (TCP)?
• TCP 3-Way Handshake Process
• Services and Segment structure in TCP
• TCP Connection Establishment
• TCP Connection Termination
• Fast Recovery Technique For Loss Recovery in TCP
• Difference Between OSI Model and TCP/IP Model

Medium Access Control

• MAC Full Form
• Channel Allocation Problem in Computer Network
• Multiple Access Protocols in Computer Network
• Carrier Sense Multiple Access (CSMA)
• Collision Detection in CSMA/CD
• Controlled Access Protocols in Computer Network

SLIDING WINDOW PROTOCOLS

• Stop and Wait ARQ
• Sliding Window Protocol | Set 3 (Selective Repeat)
• Piggybacking in Computer Networks

IP Addressing

• What is IPv4?
• What is IPv6?
• Introduction of Classful IP Addressing
• Classless Addressing in IP Addressing
• Classful Vs Classless Addressing
• Classless Inter Domain Routing (CIDR)
• Supernetting in Network Layer
• Introduction To Subnetting
• Difference between Subnetting and Supernetting
• Types of Routing
• Difference between Static and Dynamic Routing
• Unicast Routing - Link State Routing
• Distance Vector Routing (DVR) Protocol
• Fixed and Flooding Routing algorithms
• Introduction of Firewall in Computer Network

Congestion Control Algorithms

• Congestion Control in Computer Networks
• Congestion Control techniques in Computer Networks
• Computer Network | Leaky bucket algorithm
• TCP Congestion Control

Network Switching

• Circuit Switching in Computer Network
• Message switching techniques
• Packet Switching and Delays in Computer Network
• Differences Between Virtual Circuits and Datagram Networks

Application Layer:DNS

• Domain Name System (DNS) in Application Layer
• Details on DNS
• Introduction to Electronic Mail
• E-Mail Format
• World Wide Web (WWW)
• HTTP Full Form
• Streaming Stored Video
• What is a Content Distribution Network and how does it work?

CN Interview Quetions

• Top 50 Networking Interview Questions (2024)
• Top 50 TCP/IP interview questions and answers
• Top 50 IP addressing interview questions and answers
• Last Minute Notes - Computer Networks
• Computer Network - Cheat Sheet
• Network Layer
• Transport Layer
• Application Layer

Prerequisite : OSI Model

Introduction : Presentation Layer is the 6th layer in the Open System Interconnection (OSI) model. This layer is also known as Translation layer, as this layer serves as a data translator for the network. The data which this layer receives from the Application Layer is extracted and manipulated here as per the required format to transmit over the network. The main responsibility of this layer is to provide or define the data format and encryption. The presentation layer is also called as Syntax layer since it is responsible for maintaining the proper syntax of the data which it either receives or transmits to other layer(s).

Functions of Presentation Layer :

The presentation layer, being the 6th layer in the OSI model, performs several types of functions, which are described below-

• Presentation layer format and encrypts data to be sent across the network.
• This layer takes care that the data is sent in such a way that the receiver will understand the information (data) and will be able to use the data efficiently and effectively.
• This layer manages the abstract data structures and allows high-level data structures (example- banking records), which are to be defined or exchanged.
• This layer carries out the encryption at the transmitter and decryption at the receiver.
• This layer carries out data compression to reduce the bandwidth of the data to be transmitted (the primary goal of data compression is to reduce the number of bits which is to be transmitted).
• This layer is responsible for interoperability (ability of computers to exchange and make use of information) between encoding methods as different computers use different encoding methods.
• This layer basically deals with the presentation part of the data.
• Presentation layer, carries out the data compression (number of bits reduction while transmission), which in return improves the data throughput.
• This layer also deals with the issues of string representation.
• The presentation layer is also responsible for integrating all the formats into a standardized format for efficient and effective communication.
• This layer encodes the message from the user-dependent format to the common format and vice-versa for communication between dissimilar systems.
• This layer deals with the syntax and semantics of the messages.
• This layer also ensures that the messages which are to be presented to the upper as well as the lower layer should be standardized as well as in an accurate format too.
• Presentation layer is also responsible for translation, formatting, and delivery of information for processing or display.
• This layer also performs serialization (process of translating a data structure or an object into a format that can be stored or transmitted easily).

Features of Presentation Layer in the OSI model: Presentation layer, being the 6th layer in the OSI model, plays a vital role while communication is taking place between two devices in a network.

List of features which are provided by the presentation layer are:

• Presentation layer could apply certain sophisticated compression techniques, so fewer bytes of data are required to represent the information when it is sent over the network.
• If two or more devices are communicating over an encrypted connection, then this presentation layer is responsible for adding encryption on the sender’s end as well as the decoding the encryption on the receiver’s end so that it can represent the application layer with unencrypted, readable data.
• This layer formats and encrypts data to be sent over a network, providing freedom from compatibility problems.
• This presentation layer also negotiates the Transfer Syntax.
• This presentation layer is also responsible for compressing data it receives from the application layer before delivering it to the session layer (which is the 5th layer in the OSI model) and thus improves the speed as well as the efficiency of communication by minimizing the amount of the data to be transferred.

Working of Presentation Layer in the OSI model : Presentation layer in the OSI model, as a translator, converts the data sent by the application layer of the transmitting node into an acceptable and compatible data format based on the applicable network protocol and architecture.  Upon arrival at the receiving computer, the presentation layer translates data into an acceptable format usable by the application layer. Basically, in other words, this layer takes care of any issues occurring when transmitted data must be viewed in a format different from the original format. Being the functional part of the OSI mode, the presentation layer performs a multitude (large number of) data conversion algorithms and character translation functions. Mainly, this layer is responsible for managing two network characteristics: protocol (set of rules) and architecture.

Presentation Layer Protocols : Presentation layer being the 6th layer, but the most important layer in the OSI model performs several types of functionalities, which makes sure that data which is being transferred or received should be accurate or clear to all the devices which are there in a closed network. Presentation Layer, for performing translations or other specified functions, needs to use certain protocols which are defined below –

• Apple Filing Protocol (AFP): Apple Filing Protocol is the proprietary network protocol (communications protocol) that offers services to macOS or the classic macOS. This is basically the network file control protocol specifically designed for Mac-based platforms.
• Lightweight Presentation Protocol (LPP): Lightweight Presentation Protocol is that protocol which is used to provide ISO presentation services on the top of TCP/IP based protocol stacks.
• NetWare Core Protocol (NCP): NetWare Core Protocol is the network protocol which is used to access file, print, directory, clock synchronization, messaging, remote command execution and other network service functions.
• Network Data Representation (NDR): Network Data Representation is basically the implementation of the presentation layer in the OSI model, which provides or defines various primitive data types, constructed data types and also several types of data representations.
• External Data Representation (XDR): External Data Representation (XDR) is the standard for the description and encoding of data. It is useful for transferring data between computer architectures and has been used to communicate data between very diverse machines. Converting from local representation to XDR is called encoding, whereas converting XDR into local representation is called decoding.
• Secure Socket Layer (SSL): The Secure Socket Layer protocol provides security to the data that is being transferred between the web browser and the server. SSL encrypts the link between a web server and a browser, which ensures that all data passed between them remains private and free from attacks.

Please Login to comment...

Similar reads.

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

  Layer 6 Presentation Layer

De/Encryption, Encoding, String representation

The presentation layer (data presentation layer, data provision level) sets the system-dependent representation of the data (for example, ASCII, EBCDIC) into an independent form, enabling the syntactically correct data exchange between different systems. Also, functions such as data compression and encryption are guaranteed that data to be sent by the application layer of a system that can be read by the application layer of another system to the layer 6. The presentation layer. If necessary, the presentation layer acts as a translator between different data formats, by making an understandable for both systems data format, the ASN.1 (Abstract Syntax Notation One) used.

OSI Layer 6 - Presentation Layer

The presentation layer is responsible for the delivery and formatting of information to the application layer for further processing or display. It relieves the application layer of concern regarding syntactical differences in data representation within the end-user systems. An example of a presentation service would be the conversion of an EBCDIC-coded text computer file to an ASCII-coded file. The presentation layer is the lowest layer at which application programmers consider data structure and presentation, instead of simply sending data in the form of datagrams or packets between hosts. This layer deals with issues of string representation - whether they use the Pascal method (an integer length field followed by the specified amount of bytes) or the C/C++ method (null-terminated strings, e.g. "thisisastring\0"). The idea is that the application layer should be able to point at the data to be moved, and the presentation layer will deal with the rest. Serialization of complex data structures into flat byte-strings (using mechanisms such as TLV or XML) can be thought of as the key functionality of the presentation layer. Encryption is typically done at this level too, although it can be done on the application, session, transport, or network layers, each having its own advantages and disadvantages. Decryption is also handled at the presentation layer. For example, when logging on to bank account sites the presentation layer will decrypt the data as it is received.[1] Another example is representing structure, which is normally standardized at this level, often by using XML. As well as simple pieces of data, like strings, more complicated things are standardized in this layer. Two common examples are 'objects' in object-oriented programming, and the exact way that streaming video is transmitted. In many widely used applications and protocols, no distinction is made between the presentation and application layers. For example, HyperText Transfer Protocol (HTTP), generally regarded as an application-layer protocol, has presentation-layer aspects such as the ability to identify character encoding for proper conversion, which is then done in the application layer. Within the service layering semantics of the OSI network architecture, the presentation layer responds to service requests from the application layer and issues service requests to the session layer. In the OSI model: the presentation layer ensures the information that the application layer of one system sends out is readable by the application layer of another system. For example, a PC program communicates with another computer, one using extended binary coded decimal interchange code (EBCDIC) and the other using ASCII to represent the same characters. If necessary, the presentation layer might be able to translate between multiple data formats by using a common format. Wikipedia

• Data conversion
• Character code translation
• Compression
• Encryption and Decryption

The Presentation OSI Layer is usually composed of 2 sublayers that are:

CASE common application service element

Sase specific application service element, layer 7   application layer, layer 6   presentation layer, layer 5   session layer, layer 4   transport layer, layer 3   network layer, layer 2   data link layer, layer 1   physical layer.

Presentation Layer

Last Edited

What is the Presentation Layer?

Presentation Layer is the Layer 6 of the seven-layer Open Systems Interconnection (OSI) reference model . The presentation layer structures data that is passed down from the application layer into a format suitable for network transmission. This layer is responsible for data encryption, data compression, character set conversion, interpretation of graphics commands, and so on. The network redirector also functions at this layer.

Presentation Layer functions

• Translation:  Before being transmitted, information in the form of characters and numbers should be changed to bit streams. Layer 6 is responsible for interoperability between encoding methods as different computers use different encoding methods. It translates data between the formats the network requires and the format the computer.
• Encryption:  Encryption at the transmitter and decryption at the receiver
• Compression:  Data compression to reduce the bandwidth of the data to be transmitted. The primary role of  data compression  is to reduce the number of bits to be transmitted. Multimedia files, such as audio and video, are bigger than text files and compression is more important.

Role of Presentation Layer in the OSI Model

This layer is not always used in network communications because its functions are not always necessary. Translation is only needed if different types of machines need to talk with each other. Encryption is optional in communication. If the information is public there is no need to encrypt and decrypt info. Compression is also optional. If files are small there is no need for compression.

Explaining Layer 6 in video

Most real-world protocol suites, such as TCP/IP , do not use separate presentation layer protocols. This layer is mostly an abstraction in real-world networking.

An example of a program that loosely adheres to layer 6 of OSI is the tool that manages the Hypertext Transfer Protocol (HTTP) — although it’s technically considered an application-layer protocol per the TCP/IP model.

However, HTTP includes presentation layer services within it. HTTP works when the requesting device forwards user requests passed to the web browser onto a web server elsewhere in the network.

It receives a return message from the web server that includes a multipurpose internet mail extensions (MIME) header. The MIME header indicates the type of file – text, video, or audio – that has been received so that an appropriate player utility can be used to present the file to the user.

In short, the presentation layer

Makes sure that data which is being transferred or received should be accurate or clear to all the devices which are there, in a closed network.

• ensures proper formatting and delivery to and from the application layer;
• performs data encryption; and
• manages serialization of data objects.

Presentation layer and Session layer of the OSI model

There are two popular networking models: the OSI layers model and the TCP/IP layers model. The presentation layer and session layer exist only in the OSI layers models. The TCP/IP layers model merges them into the application layer.

The Presentation Layer

The presentation layer is the sixth layer of the OSI Reference model. It defines how data and information is transmitted and presented to the user. It translates data and format code in such a way that it is correctly used by the application layer.

It identifies the syntaxes that different applications use and formats data using those syntaxes. For example, a web browser receives a web page from a web server in the HTML language. HTML language includes many tags and markup that have no meaning for the end user but they have special meaning for the web browser. the web browser uses the presentation layer's logic to read those syntaxes and format data in such a way the web server wants it to be present to the user.

On the sender device, it encapsulates and compresses data before sending it to the network to increase the speed and security of the network. On the receiver device, it de-encapsulates and decompresses data before presenting it to the user.

Examples of the presentation layer

Example standards for representing graphical information: JPEG, GIF, JPEG, and TIFF.

Example standards for representing audio information: WAV, MIDI, MP3.

Example standards for representing video information: WMV, MOV, MP4, MPEG.

Example standards for representing text information: doc, xls, txt, pdf.

Functions of the presentation layer

• It formats and presents data and information.
• It encrypts and compresses data before giving it to the session layer.
• It de-encrypts and decompresses the encrypted and compressed data it receives from the session layer.

Session layer

The session layer is the fifth layer of the OSI layers model. It is responsible for initiating, establishing, managing, and terminating sessions between the local application and the remote applications.

It defines standards for three modes of communication: full duplex, half-duplex, and simplex.

In the full duplex mode, both devices can send and receive data simultaneously. The internet connection is an example of the full duplex mode.

In the half duplex mode, only one device can send data at a time. A telephone conversation is an example of the half-duplex mode.

In the simplex mode, only one device can send data. A radio broadcast is an example of the simplex mode.

Functions of the session layer

• It is responsible for terminating sessions, creating checkpoints, and recovering data when sessions are interrupted.
• It opens and maintains logical communication channels between network applications running on the local host and network applications running on the remote host.
• If a network application uses an authentication mechanism before it opens a logical communication channel (session) with the remote host, it handles the authentication process.

Examples of the session layer

Structure Query Language (SQL), Remote Procedure Call (RPC), and Network File System (NFS) are examples of the session layer.

By ComputerNetworkingNotes Updated on 2023-10-30 05:30:01 IST

ComputerNetworkingNotes CCNA Study Guide Presentation layer and Session layer of the OSI model

We do not accept any kind of Guest Post. Except Guest post submission, for any other query (such as adverting opportunity, product advertisement, feedback, suggestion, error reporting and technical issue) or simply just say to hello mail us [email protected]

Create your address on the web.

• Domain Check

Move your domain name to IONOS.

• Free Domain

Secure site traffic and build trust.

Create your own website easily.

Create your own online store.

Fast, scalable hosting for any website.

Optimized for speed, reliablity and control.

Reach out with your own email address.

Secure and share your data on the go.

Powerful Exchange email and Microsoft's trusted productivity suite.

Pay as you go with your own scalable private server.

• Virtual Private Servers (VPS)

Get enterprise hardware with unlimited traffic

Individually configurable, highly scalable IaaS cloud

• Business Name Generator
• Logo Creator
• Favicon Generator
• Whois Lookup
• Website Checker
• SSL Checker
• IP Address Check

What is the presentation layer in the OSI model?

The presentation layer is the sixth layer in the OSI model and is responsible for converting different file formats. This allows two systems to communicate. Other tasks carried out by the sixth layer include data compression and encryption.

What is the presentation layer?

What does the presentation layer do, which format does the presentation layer use, presentation layer protocols, skipping the presentation layer.

The presentation layer is the sixth layer of the OSI model. It is primarily used to convert different file formats between the sender and the receiver . The OSI model is a reference model that is used to define communication standards between two devices within a network . The development of this standard began in the 1970s and it was first published at the beginning of the following decade. This standard enables seamless interaction between different technical systems.

The model is made up of a total of seven different layers, all having their own clearly defined tasks. While there are clear boundaries between the layers, the layers interact with each other, with each layer building off the one below it. The different layers are as follows:

• Physical layer
• Data link layer
• Network layer
• Transport layer
• Session layer
• Presentation layer
• Application layer

The presentation layer interacts closely with the application layer, which is located directly above it. The presentation layer’s main task is to present data in such a way that it can be understood and interpreted from both the system sending the data and the system receiving it. After this has been accomplished, the application layer then determines how the data should be structured and what sort of data and values are permissible.

Using these entries, a command set, or an abstract transfer syntax, is then automatically created. The presentation layer now has the task of transferring the data in such a way that it is readable without changing the information contained within it.

The presentation layer is often also responsible for the encryption and decryption of data . The information is first encrypted on the sender’s side and then sent to the receiver in an encrypted state. Keys and encryption methods are then exchanged in the presentation layer. The recipient is then able to decrypt the unreadable data and convert it into a format that can be understood and interpreted.

If data is shown during a transfer, we often use the term transfer syntax. These are separated into the abstract transfer syntax , in which the transferred values are written, and the concrete syntax, which contains a definition of the value coding.

The receiver can only process and understand the data they receive if they receive all of the information from the presentation layer. The most common definition language is Abstract Syntax Notation One (ASN.1) , which is also recommended by the ISO. The ISO is an organization that is responsible for developing international standards in technology, management and manufacturing.

The presentation layer has many different formats. The most common text formats are the ASCII (American Standard Code for Information Interchange) and EBCDIC (Extended Binary-Coded Decimal Interchange Code). The most common image formats are GIF, JPEG and TIFF. Widely used video formats include MIDI, MPEG and QuickTime.

There are many different presentation layer protocols as well as transfer and encryption technologies in the presentation layer. These include:

The tasks which are carried out by the presentation layer are not always necessary for communication between two systems. In instances where both systems use the same formats, data conversion is not necessary. Additionally, encryption and compression are not required for every interaction and can also be carried out in another layer of the OSI model. If this is the case, the presentation layer can be skipped and the application layer (7) can communicate directly with the session layer (5) instead .

• Encyclopedia

Build or host a website, launch a server, or store your data and more with our most popular products for less.

The world has moved to the internet, and web applications have become the new workplaces and commercial stores. To accommodate the variety of purposes that modern web apps serve, each of them needs to be designed for high performance and customizability.

Web application architectures solve this problem. Web application architecture defines how the various components of a web-based application are structured. This architecture is highly specific to the nature and the purpose of the web application. Choosing the wrong architecture for your web app can wreak havoc on your business.

In this guide, we will break down the concept of web application architecture and understand how it affects the end-user experience of your application. Towards the end, we will also look at some of the best practices you can implement to get the most out of your web application.

What Is Web Application Architecture?

To kick off the discussion, let’s start with the definition of web application architecture.

In simple words, web application architecture is an outline of how various components of your web app interact with each other.

It can be as simple as defining the relationship between the client and the server. It can also be as complex as defining the inter-relations between a swarm of containerized backend servers, load balancers, API gateways, and user-facing single-page frontends.

That said, it’s rarely about choosing the programming language in which you will write your code.

How you design your web app plays a key role in both its usability and your cost optimization. Here’s what a sample web app architecture looks like on paper:

Why Is Web Application Architecture Important?

Web application architecture is, without a doubt, one of the most important parts of your web application. If you choose to develop your web app with a specific architecture in mind, you are certain to receive many benefits when it comes to maintaining and growing your application.

However, choosing the right architecture amplifies these benefits further.

Here are some of the top reasons you should seriously consider adopting a web application architecture.

Adapting To Business Needs Easily

Your app is a key gateway to your business, and business needs evolve with the changing market. To keep up, you’ll want your app to be flexible enough to adapt to your changing business needs. And if you build an app without considering built-in flexibility, you’re bound to spend increasing amounts of time and effort making tiny adjustments in your app down the line.

The right web application architecture already accounts for some of the changes that your business might need in the future. For instance, if you know you’re building an ecommerce application that will scale and cater a wide range of services to a large number of customers one day, choosing a microservices architecture over a monolithic one would provide you with more flexibility.

On the other hand, if you’re building an internal app for your company with only one or two fixed requirements, you can opt for a simpler monolith to speed up development and keep your codebase clean.

Organized Development

As we mentioned earlier, the right web app architecture provides you with a more convenient roadmap for development. Architecture provides enough modularity in your system to isolate components as necessary, and you get the freedom to choose the right project structure for each of your modules and components as necessary.

If you dive into app development without an architecture in mind, you risk wasting time and money re-organizing your components and laying out new rules to help facilitate collaboration between your team members — time and money which could have otherwise been spent elsewhere.

Better Codebase Management

Apart from writing your app’s code, you’ll also spend a considerable amount of time managing it. Organizing your project files, breaking your app down into modules, and setting up custom pipelines are just a few of the tasks that require active maintenance to ensure smooth development.

The right web app architecture makes it easy for you to make changes. You get to implement component-specific best practices, separate your app’s pain points from one another, and keep each feature independent and loosely coupled. It’s not that these things can’t be done without architecture; it’s just that the right architecture makes all of it much simpler.

Following a pre-defined architecture also makes it easy for you to develop your applications faster. The right architecture combined with a sound version control strategy can enable your developers to work in parallel with each other and build features faster.

A web app architecture also future-proofs your application. Once you define a solid strategy around how to organize your app’s components, you can easily migrate those components to newer technologies one by one without having to redo your entire application.

Enhanced Security

Most web app architectures factor in security when structuring components. Developers can plan, ahead of time, the measures and practices to implement to improve the app’s security before it’s rolled out to the users.

For example, building an OTT video streaming app that offers both paid and free content using microservices makes more sense as the microservices architecture enables you to split your app into business-friendly components, such as user authentication and free or paid content streaming. If your user authentication module ever goes down, you can easily configure your app to restrict access to the paid content module until auth is up while the free content module is still available to your users.

In an alternate case where this same app was designed as a tightly-coupled monolith, a downed authentication service would mean either a downed application or paid content being made available for free — outcomes you’ll want to avoid at all costs.

How Does Web Application Architecture Work?

Before we talk about how web application architecture works, it’s important to understand how a simple website works:

• The user enters your app’s URL in the browser’s address bar or clicks on a link.
• The browser looks the URL up in the DNS servers and identifies the IP address of your app.
• The browser sends an HTTP request to your app.
• Your app responds with the correct content (usually a webpage).
• The browser renders the webpage on the screen.

If you were to dive a little deeper, here’s how a web app would handle a request:

• The user sends a request to your app via your frontend user interface.
• If you have a relevant cache set up, the app would first check it to see if it has a valid record that can be sent back to the client directly. If yes, the cached content will be sent back, and the request will be marked as completed.
• If there’s no cache, the request is forwarded to the load balancer.
• The load balancer identifies a server instance that is available to handle the request and forwards it.
• The server instance processes the request and calls any external APIs if needed.
• Once the results are collected at one place, the server sends back the response to the load balancer.
• The load balancer returns the response to the API gateway, which in turn sends it down to the user in the frontend client. The request is then marked as completed.

Types of Web Application Architecture

Now that you have a basic idea of what web application architecture is let’s take a detailed look at some of the popular types of web application architecture used throughout the web.

Single-Page Architecture

The architecture for a single-page application (SPA) is as simple as its name: The entire application is based on a single page. Once the user pulls up your app, they do not need to navigate to any other web pages. The app is made dynamic enough to fetch and render screens that meet users’ requirements as they navigate through the app itself.

SPAs are great when it comes to providing a fast and seamless experience to end-users or consumers. However, they lack the touch of a traditional website, and they can be difficult to optimize for SEO .

Pros of SPA Architecture

Some of the pros of SPA architecture include:

• You can build highly interactive web apps.
• SPAs are easy to scale.
• Optimizing SPAs for performance does not require much effort.

Cons of SPA Architecture

A few of the drawbacks of SPA architecture are:

• SPAs limit the flexibility with hyperlinks and SEO.
• The initial render is usually slow.
• Navigation through the app can be unintuitive.

Progressive Web Application Architecture

The Progressive Web Application (PWA) architecture builds on top of the Single Page Architecture by providing offline capabilities for your web app. Technologies such as Capacitor and Ionic are used to build PWAs that can provide users with a uniform experience across platforms.

Similar to SPAs, PWAs are smooth and seamless. With the added ability of being installed on user devices (via service workers), your users get a more uniform experience with your application.

At the same time, it can be tough to optimize such apps for SEO, and updates on installed apps can be difficult to push.

Pros of PWA Architecture

There are many benefits of PWA architecture, including:

• Apps run very smoothly and offer cross-platform compatibility.
• Scalability is simple.
• Offline access and device-native APIs such as background workers and push notifications are accessible to developers.

Cons of PWA Architecture

Some of the cons of PWA architecture can include:

• There is limited support for link management and SEO.
• Pushing updates to offline PWAs is more complex than with native apps.
• There is limited support for PWAs across web browsers and operating systems.

Server-side-rendered Architecture

In server-side rendering (SSR), frontend web pages are rendered on a backend server after they are requested by the user. This helps to reduce the load on the client device as it receives a static HTML, CSS, and JS webpage.

SSR apps are very popular among blogs and ecommerce websites. This is because they make link management and SEO quite simple. Also, the first render for SSR apps is quite fast since the client isn’t required to process any JS code to render the screens.

Pros of SSR Architecture

Some of the pros of SSR architecture are listed below:

• These apps are great for SEO-heavy websites.
• The first-page load is nearly instant in most cases.
• You can pair it up with a caching service to further improve your app’s performance.

Cons of SSR Architecture

A few drawbacks to using SSR architecture include:

• It is not recommended for complex or heavy web pages since the server can take time to fully generate the page resulting in a delayed first render.
• It is mostly recommended for apps that do not focus much on the user interface and are only looking for increased scalability or security.

Pre-rendered Applications Architecture

Pre-rendered applications architecture is also known as static site generation architecture. In this architecture, the frontend web pages of the app are pre-generated and stored as plain HTML, CSS, and JS files on the server. Once a user requests for a page, it is directly fetched and shown to them. This makes the web app very fast, with minimal load times of any type. However, this architecture adds to the built time of the app since the web pages are rendered during the build process.

Pre-rendered web apps are great for when you are looking to generate static content such as blogs or product details that don’t change often. You can also make use of templates to simplify your web page design. However, it is nearly impossible to build dynamic web apps with this architecture. If you are looking to build a search page that takes the query in its path (something like https://myapp.com/search/foo+bar ), you are in the wrong place.

Since each possible route of the app is pre-rendered during the build process, it is impossible to have dynamic routes as above since there are infinite possibilities that can not be pre-rendered during the build (and it doesn’t make sense to do so either).

Pros of Pre-rendered Architecture

A few of the top benefits of pre-rendered applications architecture are:

• Web pages are generated in pure HTML, CSS, and JS; hence their performance is similar to that of apps built using vanilla JS.
• If you know your app’s all possible routes, SEO becomes super easy.

Cons of Pre-rendered Architecture

As with any architectural model, pre-rendered has its share of drawbacks:

• Dynamic content can not be served with these apps.
• Making any change to the web app means completely rebuilding and deploying the app from scratch.

Isomorphic Application Architecture

Isomorphic apps are those that are a mixture of server-side-rendered apps and SPAs. This means that such apps are first rendered on the server as a normal server-side-rendered app. Once they are received by the client, the app hydrates itself and attaches the virtual DOM for faster and more efficient client processing. This essentially turns the app into a single-page application.

Isomorphic brings the best of both worlds together. You get super-fast processing and user interface on the client, thanks to the SPA. You also get quick initial render and full-fledged SEO and linking support, thanks to the server-side rendering.

Pros of Isomorphic Architecture

Here are just some of the benefits to using isomorphic application architecture:

• Isomorphic apps have super quick initial render and full support for SEO.
• These apps also perform well on the client since they turn into a SPA after loading.

Cons of Isomorphic Architecture

Some of the cons of isomorphic application architecture can be:

• Setting up such an app requires skilled talent.
• Options of tech stack are limited when it comes to designing an isomorphic app. You only get to choose from a handful of (mostly) JS-based libraries and frameworks.

Service-oriented Architecture

The service-oriented architecture is among the most popular alternatives to the traditional monolith way of building apps. In this architecture, the web apps are broken down into services that represent a functional unit of business each. These services are loosely coupled together and interact with each other via the medium of message passing.

Service-oriented architecture adds stability and scalability to your application tech stack. However, the size of services in SOA is not clearly defined and is usually tied to business components, not technical components; hence maintenance can sometimes be an issue.

Pros of Service-oriented Architecture

The main benefits of service-oriented architecture include:

• This architecture helps to build highly scalable and reliable apps.
• Components are reusable and are shared to enhance development and maintenance efforts.

Cons of Service-oriented Architecture

Here’s a list of potential drawbacks to using service-oriented architecture:

• SOA apps are still not 100% flexible since the size and scope of each service are not fixed. There can be services the size of enterprise applications that can be difficult to maintain.
• Component sharing introduces dependencies between services.

Microservices Architecture

The microservices architecture was designed to solve the issues with the service-oriented architecture. Microservices are even more modular components that fit together to build a web app. However, microservices focus on keeping each component small and with a bounded context. Bounded context essentially means that each microservice has its code and data coupled together with minimal dependencies on other microservices.

The microservices architecture is probably the best architecture to build apps that aim to scale to thousands and millions of users someday. Each component is resilient, scalable, and easy to maintain. However, maintaining the DevOps lifecycle for a microservices-based app requires additional efforts; hence it might not suit well for smaller use-cases.

Pros of Microservices Architecture

Some pros of microservices architecture include:

• App components are highly modular, independent, and can be re-used to a greater extent than those of the service-oriented architecture.
• Each component can be scaled independently to meet varying user traffic.
• Microservices-based apps are highly fault-tolerant.

Cons of Microservices Architecture

A drawback of microservices architecture can be:

• For smaller projects, the microservices architecture might require too much effort to maintain.

Serverless Architecture

The serverless architecture is another hot entrant in the world of web app architectures. This architecture focuses on breaking down your application in terms of the functions that it is supposed to carry out. Then these functions are hosted on FaaS (Function-as-a-Service) platforms as functions that are invoked as and when requests come in.

Unlike most other architectures on this list, apps built using the serverless architecture do not stay running all the time. They behave just like functions would do — wait for being called, and upon being called, run the defined process and return a result. Due to this nature, they cut down on maintenance costs and are highly scalable without much effort. However, it is difficult to carry out long-running tasks using such components.

Pros of Serverless Architecture

Here are the key benefits of serverless architecture:

• Serverless apps are highly and easily scalable. They can even adapt to the incoming traffic in real-time to reduce the load on your infrastructure.
• Such apps can make use of the pay-per-use pricing model of serverless platforms to reduce infrastructure costs.
• Serverless apps are quite easy to build and deploy since all you have to do is write a function and host it on a platform like Firebase functions, AWS Lambda, etc.

Cons of Serverless Architecture

Below are some of the drawbacks to serverless architecture:

• Long-running tasks can be costly to do on such an architecture.
• When a function receives a request after a long time, it is known as a cold start. Cold starts are slow and can provide a bad experience to your end-user.

Layers of Web Application Architecture

While web application architectures that you saw above might all look quite different from each other, their components can be logically grouped together into definite layers that help achieve a business goal.

Presentation Layer

The presentation layer accounts for everything in a web app that’s exposed to the end-users. Primarily, the presentation layer is composed of the frontend client. However, it also incorporates any logic that you have written on your backend to make your frontend dynamic. This gives you the room to serve your users with UI custom-tailored to their profile and requirements.

Three fundamental technologies are used to build this layer: HTML, CSS, and JavaScript. HTML lays out your frontend, CSS styles it, and JS puts life into it (i.e., controls its behavior when users interact with it). On top of these three technologies, you can use any kind of framework to help make your development easy. Some common frontend frameworks include Laravel , React, NextJS, Vue, GatsbyJS, etc.

Business Layer

The business layer is responsible for holding and managing your app’s working logic. It is usually a backend service that accepts requests from the client and processes them. It controls what the user can access and determines how the infrastructure is utilized to serve user requests.

In the case of a hotel booking app, your client app serves as a portal for users to type hotel names and other relevant data. However, as soon as the user clicks on the search button, the business layer receives the request and kicks off the logic for looking for available hotel rooms that match your requirements. The client then just receives a list of hotel rooms without any knowledge of how this list was generated or even why the list items are arranged in the way that they have been sent.

The presence of such a layer ensures that your business logic is not exposed to your client and, ultimately, users. Isolating the business logic helps immensely in sensitive operations such as handling payments or managing health records.

Persistence Layer

The persistence layer is responsible for controlling access to your data stores. This acts as an added layer of abstraction between your datastores and your business layer. It receives all data-related calls from the business layers and processes them by making secure connections to the database.

This layer usually consists of a database server . You can set this layer yourself by provisioning a database and a database server in your on-prem infrastructure or opt for a remote/managed solution by one of the leading cloud infrastructure providers like AWS, GCP, Microsoft Azure, etc.

Web Application Components

Now that you understand what goes into a web application architecture let’s take a detailed look into each of the components that compose a web app. We’ll group this discussion into two major headings — server-side components and client-side components, or backend and frontend components.

Server-side Components

Server-side components are those that reside on the backend of your web application. These are not exposed directly to the users and hold the most important business logic and resources for your web app.

DNS & Routing

DNS is responsible for controlling how your app is exposed to the web. DNS records are used by HTTP clients, which could be a browser as well, to find and send requests to your app’s components. DNS is also used by your frontend clients internally to resolve the location of your web servers and API endpoints to send requests and process user operations.

Load balancing is another popular component of web application architecture. A load balancer is used to distribute HTTP requests between multiple identical web servers. The intent behind having multiple web servers is to maintain redundancy that helps increase fault tolerance as well as distribute traffic to maintain high performance.

API endpoints are used to expose backend services to the frontend application. These help to facilitate communication between the client and the server, and sometimes even between multiple servers as well.

Data Storage

Data storage is a crucial part of most modern applications as there are always some app data that needs to be persisted across user sessions. Data storage is of two types:

• Databases: Databases are used to store data for fast access. Usually, they support storing a small amount of data that is regularly accessed by your application.
• Data Warehouses: Data warehouses are meant for the preservation of historical data. These are usually not needed very often in the app but are processed regularly to generate business insights.

Caching is an optional feature often implemented in web app architectures to serve content faster to the users. A large portion of app content is often repetitive for some amount of time, if not always. Instead of accessing it from a data store and processing it before sending it back to the user, it is often cached. Here are the two most popular types of caching used across web applications:

• Data caching: Data caching introduces a way for your app to easily and quickly access regularly used data that does not change often. Technologies such as Redis and Memcache enable caching data to save on expensive database queries just to retrieve the same data again and again.
• Web page caching: A CDN (Content Delivery Network) caches web pages the same way as Redis caches data. Similar to how only data that does not change often is cached, usually only static web pages are recommended to be cached. For server-side-rendered web apps, caching does not do much good since their content is supposed to be highly dynamic.

Jobs and Services

Apart from exposing an interface to users (frontend) and handling their requests (backend), there is another slightly less popular category of web app components. Jobs are often background services that are meant to complete tasks that are not time-sensitive or synchronous.

CRON jobs are those that are run on a fixed time period again and again. These jobs are scheduled on the backend to run maintenance routines automatically at set times. Some common example use-cases for these include deleting duplicates/old records from the database, sending out reminder emails to customers, etc.

Client-Side Components

Client-side components are those that are exposed to your users either directly or indirectly.

There are mainly two types of components in this category.

Frontend User Interface

The user interface is the visual aspect of your application. It is what your users see and interact with in order to access your services.

The frontend interface is mostly built on three popular technologies: HTML, CSS, and JavaScript . The frontend user interface can be an application in itself with its own software development life cycle.

These user interfaces don’t house a lot of your business logic since they’re exposed directly to your users. If a malicious user tries to reverse engineer your frontend application, they can get information on how your business works and carry out illegal activities like brand impersonation and data theft.

Also, since the frontend user interface is exposed directly to users, you’ll want to optimize it for minimal loading time and responsiveness. Sometimes this can help you provide a better experience to your users, thereby increasing your business growth.

Client-Side Business Logic

Sometimes you might need to store some business logic on your client in order to perform simpler operations quickly. Client-side logic that usually resides inside your frontend application can help you skip the trip to the server and provide your users with a faster experience.

This is an optional feature of the client-side components. In some cases, the app’s business logic is stored entirely on the client-side (especially when building without a traditional backend server ). Modern solutions such as BaaS help you access common operations such as authentication, data storage, file storage, etc., on the go in your frontend app.

There are ways to obfuscate or minify this code before rolling it out to your users to minimize the chances of reverse-engineering.

Models of Web Application Components

There are multiple models of web application architectures, each based on how web servers connect to their data stores.

One Server, One Database

The simplest model of all is one web server connecting to one database instance. Such a model is easy to implement and maintain, and going to production with it is also fairly effortless.

Due to its simplicity, this model is suitable for learning and for small experimental applications that will not be exposed to high traffic. Novice developers can easily set up and tinker with these apps to learn the fundamentals of web app development .

However, this model shouldn’t be used in production since it’s highly unreliable. An issue in either the server or the database can result in downtime and lost business.

Multiple Servers, One Database

This model takes the application up a notch by setting up multiple servers for redundancy with a single common database instance.

Since multiple web servers access the database simultaneously, inconsistency issues can occur. To avoid that, the web servers are designed to be stateless. This means the servers don’t retain data across sessions; they merely process it and store it in the database.

Apps made using this model are certainly more reliable than those with the previous model, as the presence of multiple web servers adds to the fault tolerance of the web app. However, since the database is still one common instance, it is the weakest link in the architecture and can be a source of failure.

Multiple Servers, Multiple Databases

This model is one of the most common, traditional models of designing web applications.

In this case, deploy your application logic as multiple identical web server instances clubbed together behind a load balancer. Your data store is also maintained across multiple database instances for added fault tolerance.

You can also choose to split your database among the available instances to enhance performance or maintain duplicates of the entire data store for redundancy. In either case, failure in any one instance of your database will not lead to a complete application outage.

This model is highly appreciated for its reliability and scalability. However, developing and maintaining apps using this model is relatively complicated and requires costly, seasoned developers . As such, this model is only suggested when you’re building on a large scale.

App Services

While the three models mentioned above are well suited to monolithic applications, there’s another model for modular applications.

The application services model breaks down an app into smaller modules based on business functionality. These modules could be as small as a function or as large as a service.

The idea here is to make each business feature independent and scalable. Each of these modules can connect to the database on its own. You can even have dedicated database instances to match your module’s scalability needs.

Among non-monolithic apps, this model is quite popular. Legacy monoliths are often migrated to this model to make use of its scalability and modularity benefits. However, managing apps built on such a model often requires seasoned developers , especially experience in DevOps and CI/CD.

Best Practices for Web Application Architecture

Here are some best practices you can implement in your web application project to get the most out of your chosen web app architecture.

1. Make Your Frontend Responsive

This can’t be stressed enough: Always aim for responsive frontends . No matter how huge and complex your web app internally is, it’s all exposed to your users via frontend web pages, apps, and screens.

If your users find these screens to be unintuitive or slow, they won’t stick around long enough to view and admire the engineering marvel that is your web app.

Therefore, designing accessible, easy-to-use, lightweight frontends is very important.

There are ample UI/UX best practices available around the web to help you understand what works best for your users. You can find professionals skilled at making user-friendly designs and architectures that can enable your users to get the most out of your apps.

We advise giving serious thought to your frontend’s responsiveness before rolling out your product to your users.

2. Monitor Load Times

Apart from being easy to understand, your frontends also need to be quick to load .

According to Portent , the highest ecommerce conversion rates occur on pages with load times between 0–2 seconds, and according to Unbounce , around 70% of consumers admit that page loading time is an important factor in their choice to purchase from an online seller.

When designing mobile-native applications, you can’t usually be certain of your users’ device specifications. Any device that doesn’t meet your app’s requirements is typically declared to not support the app.

However, this is quite different with the web.

When it comes to web applications, your users could be using anything from the latest Apple Macbook M1 Pros to vintage Blackberry and Nokia phones to view your app. Optimizing your frontend experience for such a wide range of users can be tough at times.

Services like LightHouse and Google PageSpeed come to mind when talking about frontend performance. You should use such tools to benchmark your frontend app before deploying it in production. Most such tools provide you with a list of actionable tips to help improve your app’s performance as much as possible.

The final 5–10% of the app’s performance is usually specific to your use case and can only be fixed by somebody who knows your app and its technologies well. It never hurts to invest in web performance !

3. Prefer PWA Wherever Possible

As discussed earlier, PWAs are the designs of the future. They can fit most use cases well, and they provide the most uniform experience across major platforms.

You should consider using PWA for your app as frequently as possible. The native experience across web and mobile is hugely impactful for your users and can reduce a lot of your own workload as well.

PWAs are also fast to load, easy to optimize, and quick to build. Opting for PWAs can help you shift a lot of your focus from development to business early on.

Keep Your Codebase Clean and Succinct

A clean codebase can help you spot and resolve most issues before they cause damage. Here are some tips you can follow to ensure that your codebase isn’t causing you any more trouble than it should.

• Focus on code reuse: Maintaining copies of the same code throughout your codebase is not only redundant, but it can also cause discrepancies to creep in, making your codebase difficult to maintain. Always focus on re-using code wherever possible.
• Plan your project structure: Software projects can grow very large with time. If you don’t begin with a planned structure of code organization and resources, you might end up spending more time finding files than writing useful code.
• Write unit tests: Every piece of code has a chance of breaking. Testing all of it manually is not feasible, so you need a fixed strategy for automating tests for your codebase. Test runners and code coverage tools can help you identify if your unit testing efforts are yielding the desired results.
• High modularity: When writing code, always focus on modularity. Writing code that is tightly coupled to other pieces of code makes it difficult to test, re-use, and alter when needed.

5. Automate Your CI/CD Processes

CI/CD stands for Continuous Integration/ Continuous Deployment . CI/CD processes are crucial to the development of your application as they help you to build, test, and deploy your project with ease.

However, you don’t want to have to run them manually each time. You should instead set up pipelines that trigger automatically based on your project’s activities. For instance, you could set up a pipeline that runs your tests automatically whenever you commit your code to your version control system . There are plenty of more complex use cases, too, such as generating cross-platform artifacts from your code repository whenever a release is created.

The possibilities are endless, so it’s up to you to figure out how you can make the most out of your CI/CD pipelines.

6. Incorporate Security Features

Most modern apps are made of multiple components. Take the following app as an example:

Client requests are routed to the app through an API gateway. While this one currently only allows direct requests to the home module of the app, in the future, it could allow for access to more components without going through the home module.

Next up, the home module checks an external authentication BaaS before allowing access. Once authenticated, the client can access the “Update Profile” or “View Profile” pages. Both these pages interact with a common, managed database solution that handles the profile data.

As you can see, the application seems like a very basic and minimal version of an online people directory . You can add/update your own profile or view other profiles available.

Here’s a quick legend of the various components in the architecture:

• Blue boxes: App modules, which are possibly hosted as microservices or serverless functions.
• Red boxes: External BaaS components that provide for authentication and database.
• Green box: Routing component that moderates incoming requests from the client.
• Black box: Your client application exposed to the user.

The components of each of the colors above are vulnerable to various kinds of security threats. Here are a few security constructs you can put in place to minimize your exposure:

• Isolate app secrets and manage them independently of your source code
• Maintain access controls through IAM services
• Improve your testing efforts to also look for security threats through techniques such as SAST
• Set up access controls through their IAM modules to regulate access
• Opt for API rate limiting
• For services such as databases, set up finer control permissions, such as who can access the profiles’ data, who can view the users’ data, and more. Many services, like Firebase , provide a detailed set of such rules.
• Like all other components, implement access controls
• Set up authorization
• Double-check on standard best practices such as CORS
• Ensure that no app secrets are available to your client
• Obfuscate your client code to minimize the chances of reverse engineering

While these are just a handful of suggestions, they stand to make the point that app security is complicated, and it’s your responsibility to ensure that you’re not leaving any loose ends for attackers to pull on. You cannot rely on a central security component to protect your business; app security is distributed across your app architecture.

7. Collect User Feedback

User feedback is a crucial tool to understand how well your app is doing in terms of business and technical performance. You can build the lightest and the smoothest app in the world, but if it doesn’t let your users do what they expect, then all your efforts go down the drain.

There are multiple ways to collect user feedback. While a quick and anonymized survey is the conventional approach, you could also go for a more sophisticated solution, such as a heat map of your users’ activity.

The choice of feedback collection method is less important than taking action on the collected feedback. Customers love businesses that listen to their problems. Giants like McDonald’s and Tesla do it, and that’s one of the reasons why they continue to succeed in their markets.

The web is a huge playground of a variety of applications, each designed in its own unique way. Multiple types of architectures make way for web apps to diversify, thrive, and offer services to users all across the globe. In this guide, we broke down the different models of web app architecture and showed you how crucial they are to an application’s growth.

Is there a web app architecture that you really loved? Or is there another that you’d like to share with the world? Let us know in the comments below!

Kumar is a software developer and a technical author based in India. He specializes in JavaScript and DevOps. You can learn more about his work on his website .

Related Articles and Topics

Backend vs Frontend: How Are They Different?

Node.js vs Python: Choose the Best Technology for Your Web App

• Website Security
• Digital Marketing
• Local Development

Very well explain and written 👏

Leave a Reply Cancel reply

By submitting this form: You agree to the processing of the submitted personal data in accordance with Kinsta's Privacy Policy , including the transfer of data to the United States.

You also agree to receive information from Kinsta related to our services, events, and promotions. You may unsubscribe at any time by following the instructions in the communications received.

COMPUTER NETWORK BASICS

• Introduction To Computer Networks
• Uses of Computer Networks
• Line Configuration
• Types of Network Topology
• Transmission Modes
• Transmission Mediums
• Bounded/Guided Transmission Media
• UnBounded/UnGuided Transmission Media
• Types of Communication Networks
• Connection Oriented and Connectionless Services
• Network Layer
• Quality of Service(QoS)
• IGMP Protocol
• Reference Models

Physical Layer

• Digital Transmission
• Multiplexing
• Circuit-Switched
• Message-Switched Networks
• Packet Switching

Data link layer

• Error Correction
• Data Link Control
• Flow and Error
• Simplest Protocol
• Stop-and-Wait Protocol
• Go-Back-N Automatic Repeat
• Sliding Window Protocol
• HDLC Protocol
• Point-to-Point Protocol
• Multiple Access in DL
• Channelization Protocols
• Gigabit Ethernet
• Random Access Protocol
• Controlled Access Protocols
• Carrier Sense Multiple Access

Transport layer

• Transport Layer
• Telnet vs SSH
• UDP Protocol
• TCP - Protocol

ISO/OSI REFERENCE MODEL

• Introduction to Reference Models
• OSI Model: Physical Layer
• OSI Model: Datalink Layer
• OSI Model: Network Layer
• OSI Model: Transport Layer
• OSI Model: Session Layer
• OSI Model: Presentation Layer
• OSI Model: Application Layer

TCP/IP REFERENCE MODELCOMPUTER NETWORKS

• The TCP/IP Reference Model
• Difference between OSI and TCP/IP Model
• Key Terms - Computer Network

Session layer

• Session Layer

Computer Networks

• Components of Computer Networks
• Features of Computer Network
• Protocols and Standards
• Connection Oriented and Connectionless
• OSI Vs TCP/IP

Presentation layer

• Presentation Layer

Application layer

• HTTP Protocol
• FTP Protocol
• SMTP Protocol
• POP Protocol
• SNMP Protocol
• Electronic Mail
• MIME Protocol
• World Wide Web
• DNS Protocol

Presentation Layer - OSI Model

The primary goal of this layer is to take care of the syntax and semantics of the information exchanged between two communicating systems. Presentation layer takes care that the data is sent in such a way that the receiver will understand the information(data) and will be able to use the data. Languages(syntax) can be different of the two communicating systems. Under this condition presentation layer plays a role translator.

In order to make it possible for computers with different data representations to communicate, the data structures to be exchanged can be defined in an abstract way. The presentation layer manages these abstract data structures and allows higher-level data structures(eg: banking records), to be defined and exchanged.

Functions of Presentation Layer

• Translation: Before being transmitted, information in the form of characters and numbers should be changed to bit streams. The presentation layer is responsible for interoperability between encoding methods as different computers use different encoding methods. It translates data between the formats the network requires and the format the computer.
• Encryption: It carries out encryption at the transmitter and decryption at the receiver.
• Compression: It carries out data compression to reduce the bandwidth of the data to be transmitted. The primary role of Data compression is to reduce the number of bits to be 0transmitted. It is important in transmitting multimedia such as audio, video, text etc.

Design Issues with Presentation Layer

• To manage and maintain the Syntax and Semantics of the information transmitted.
• Encoding data in a standard agreed upon way. Eg: String, double, date, etc.
• Perform Standard Encoding on wire.
• ← Prev
• Next →

  CN MCQ Tests

  gate interview tests.

Presentation Layer: Protocols, Examples, Services | Functions of Presentation Layer

Presentation Layer is the 6th layer in the Open System Interconnection (OSI) model where all application programmer consider data structure and presentation, beyond of simply sending the data into form of datagram otherwise packets in between the hosts. Now, we will explain about what is presentation layer with its protocols, example, service ; involving with major functions of presentation Layer with ease. At the end of this article, you will completely educate about What is Presentation Layer in OSI Model without any hassle.

• What is Presentation Layer?

Definition : Presentation layer is 6th layer in the OSI model , and its main objective is to present all messages to upper layer as a standardized format. It is also known as the “ Translation layer “.  This layer takes care of syntax and semantics of messages exchanged in between two communication systems. Presentation layer has responsible that receiver can understand all data, and it will be to implement all data languages can be dissimilar of two communication system.

Presentation layer is capable to handle abstract data structures, and further it helps to defined and exchange of higher-level data structures.

Presentation Layer Tutorial Headlines:

In this section, we will show you all headlines about this entire article; you can check them as your choice; below shown all:

• Functions of Presentation Layer

Protocols of Presentation Layer

• Example of Presentation Layer Protocols

Presentation Layer Services

Design issues with presentation layer, faqs (frequently asked questions), what is meant by presentation layer in osi model, what protocols are used in the presentation layer, can you explain some presentation layer examples, what are the main functions of the presentation layer, what are services of presentation layer in osi, let’s get started,   functions of presentation layer.

Presentation layer performs various functions in the OSI model ; below explain each one – 

• Presentation layer helps to translate from American standard code for information interchange (ASCII) to the extended binary code decimal interchange code (EBCDIC).
• It deals with user interface as well as supporting for several services such as email and file transfer.
• It provides encoding mechanism for translating all messages from user dependent format with common format and vice – versa.
• It’s main goal for data encryption and decryption of entire data before they are getting transmission over all common platforms.
• It provides data compression mechanism for source point to decrease the all bits which are transmitted. Due to this data compression system, user are able to transmit enlarge multimedia file at fastest file transfer rate.
• Due to use of Data Encryption and Decryption algorithm, presentation layer provides more network protection and confidentiality while transmission data over the entire network.
• This layer offers best flexibility for data translation for making connections with various kinds of servers , computers, and mainframes over the similar network.
• Presentation layer has responsible to fix all translations in between all network systems .

Presentation layer is used various protocols; below list is available –

• Multipurpose Internet Mail Extensions
• File Transfer Protocol
• Network News Transfer Protocol
• Apple Filing Protocol (AFP)
• Independent Computing Architecture (ICA), the Citrix system core protocol
• Lightweight Presentation Protocol (LPP)
• NetWare Core Protocol (NCP)
• Network Data Representation (NDR)
• Telnet (a remote terminal access protocol)
• Tox Protocol
• eXternal Data Representation (XDR)
• 25 Packet Assembler/Disassembler Protocol (PAD)

Example of Presentation Layer Protocols:

Here, we will discuss all examples of presentation layer protocols; below explain each one –  

Multipurpose Internet Mail Extensions (MIME) : MIME protocol was introduced by Bell Communications in 1991, and it is an internet standard that provides scalable capable of email for attaching of images, sounds and text in a message.

File Transfer Protocol (FTP) : FTP is a internet protocol, and its main goal is to transmit all files in between one host to other hosts over the internet on TCP/IP connections.

Network News Transfer Protocol (NNTP) : This protocol is used to make connection with Usenet server and transmit all newsgroup articles in between system over internet.

Apple Filing Protocol (AFP ) : AFP protocol is designed by Apple company for sharing all files over the entire network .

Lightweight Presentation Protocol (LPP) : This protocol is used to offer ISO presentation services on top of TCP/IP based protocol stacks.

NetWare Core Protocol (NCP) : NCP is a Novell client server model protocol that is designed especially for Local Area Network (LAN). It is capable to perform several functions like as file/print-sharing, clock synchronization, remote processing and messaging.

Network Data Representation (NDR) : NDR is an data encoding standard, and it is implement in the Distributed Computing Environment (DCE).

Telnet (Telecommunication Network) : Telnet protocol was introduced in 1969, and it offers the command line interface for making communication along with remote device or server .

Tox : The Tox protocol is sometimes regarded as part of both the presentation and application layer , and it is used for sending peer-to-peer instant-messaging as well as video calling.

eXternal Data Representation (XDR) : This protocol provides the description and encoding of entire data, and  it’s main goal is to transfer data in between dissimilar computer architecture.

25 Packet Assembler/Disassembler Protocol (PAD) : Main objective of this protocol is to obtain all data from group of terminal and allots the data into X. 25 packets.

Presentation layer provides several services like as –

• Data conversion
• Character code translation
• Compression
• Encryption and Decryption
• It helps to handle and maintain Syntax and Semantics of the message transmitted.
• Encoding data can be done as standard agreed like as String, double, date, and more.
• Standard Encoding can be done on wire.

Presentation Layer is the 6th layer in the Open System Interconnection (OSI) model that is the lowest layer, where all application programmer consider data structure and presentation, beyond of simply sending the data into form of datagram otherwise packets in between the hosts.

Presentation layer is used various protocols like as:

Yes! In this article, already we have been explained many examples of presentation layer; you can check them.

Presentation layer has a responsibility for formatting, translation, and delivery of the information for getting to process otherwise display .

Now, i hope that you have completely learnt about what is presentation layer with its protocols, example, service ; involving with major functions of presentation Layer with ease. If this post is useful for you, then please share it along with your friends, family members or relatives over social media platforms like as Facebook, Instagram, Linked In, Twitter, and more.

Also Read: Data Link Layer: Protocols, Examples | Functions of Data Link Layer

If you have any experience, tips, tricks, or query regarding this issue? You can drop a comment!

Related Posts

Software Architecture Patterns by

Get full access to Software Architecture Patterns and 60K+ other titles, with a free 10-day trial of O'Reilly.

There are also live events, courses curated by job role, and more.

Chapter 1. Layered Architecture

The most common architecture pattern is the layered architecture pattern, otherwise known as the n-tier architecture pattern. This pattern is the de facto standard for most Java EE applications and therefore is widely known by most architects, designers, and developers. The layered architecture pattern closely matches the traditional IT communication and organizational structures found in most companies, making it a natural choice for most business application development efforts. 

Pattern Description

Components within the layered architecture pattern are organized into horizontal layers, each layer performing a specific role within the application (e.g., presentation logic or business logic). Although the layered architecture pattern does not specify the number and types of layers that must exist in the pattern, most layered architectures consist of four standard layers: presentation, business, persistence, and database ( Figure 1-1 ). In some cases, the business layer and persistence layer are combined into a single business layer, particularly when the persistence logic (e.g., SQL or HSQL) is embedded within the business layer components. Thus, smaller applications may have only three layers, whereas larger and more complex business applications may contain five or more layers. 

Each layer of the layered architecture pattern has a specific role and responsibility within the application. For example, a presentation layer would be responsible for handling all user interface and browser communication logic, whereas a business layer would be responsible for executing specific business rules associated with the request. Each layer in the architecture forms an abstraction around the work that needs to be done to satisfy a particular business request. For example, the presentation layer doesn’t need to know or worry about how to get customer data; it only needs to display that information on a screen in particular format. Similarly, the business layer doesn’t need to be concerned about how to format customer data for display on a screen or even where the customer data is coming from; it only needs to get the data from the persistence layer, perform business logic against the data (e.g., calculate values or aggregate data), and pass that information up to the presentation layer.  

Figure 1-1. Layered architecture pattern

One of the powerful features of the layered architecture pattern is the separation of concerns among components. Components within a specific layer deal only with logic that pertains to that layer. For example, components in the presentation layer deal only with presentation logic, whereas components residing in the business layer deal only with business logic. This type of component classification makes it easy to build effective roles and responsibility models into your architecture, and also makes it easy to develop, test, govern, and maintain applications using this architecture pattern due to well-defined component interfaces and limited component scope.

Key Concepts

Notice in Figure 1-2 that each of the layers in the architecture is marked as being  closed . This is a very important concept in the layered architecture pattern. A closed layer means that as a request moves from layer to layer, it must go through the layer right below it to get to the next layer below that one. For example, a request originating from the presentation layer must first go through the business layer and then to the persistence layer before finally hitting the database layer. 

Figure 1-2. Closed layers and request access

So why not allow the presentation layer direct access to either the persistence layer or database layer? After all, direct database access from the presentation layer is much faster than going through a bunch of unnecessary layers just to retrieve or save database information. The answer to this question lies in a key concept known as  layers of isolation . 

The layers of isolation concept means that changes made in one layer of the architecture generally don’t impact or affect components in other layers: the change is isolated to the components within that layer, and possibly another associated layer (such as a persistence layer containing SQL). If you allow the presentation layer direct access to the persistence layer, then changes made to SQL within the persistence layer would impact both the business layer and the presentation layer, thereby producing a very tightly coupled application with lots of interdependencies between components. This type of architecture then becomes very hard and expensive to change.  

The layers of isolation concept also means that each layer is independent of the other layers, thereby having little or no knowledge of the inner workings of other layers in the architecture. To understand the power and importance of this concept, consider a large refactoring effort to convert the presentation framework from JSP (Java Server Pages) to JSF (Java Server Faces). Assuming that the contracts (e.g., model) used between the presentation layer and the business layer remain the same, the business layer is not affected by the refactoring and remains completely independent of the type of user-interface framework used by the presentation layer.  

While closed layers facilitate layers of isolation and therefore help isolate change within the architecture, there are times when it makes sense for certain layers to be open. For example, suppose you want to add a shared-services layer to an architecture containing common service components accessed by components within the business layer (e.g., data and string utility classes or auditing and logging classes). Creating a services layer is usually a good idea in this case because architecturally it restricts access to the shared services to the business layer (and not the presentation layer). Without a separate layer, there is nothing architecturally that restricts the presentation layer from accessing these common services, making it difficult to govern this access restriction.  

In this example, the new services layer would likely reside  below  the business layer to indicate that components in this services layer are not accessible from the presentation layer. However, this presents a problem in that the business layer is now required to go through the services layer to get to the persistence layer, which makes no sense at all. This is an age-old problem with the layered architecture, and is solved by creating open layers within the architecture.  

As illustrated in Figure 1-3 , the services layer in this case is marked as open,  meaning requests are allowed to bypass this open layer and go directly to the layer below it. In the following example, since the services layer is open, the business layer is now allowed to bypass it and go directly to the persistence layer, which makes perfect sense.  

Figure 1-3. Open layers and request flow

Leveraging the concept of open and closed layers helps define the relationship between architecture layers and request flows and also provides designers and developers with the necessary information to understand the various layer access restrictions within the architecture. Failure to document or properly communicate which layers in the architecture are open and closed (and why) usually results in tightly coupled and brittle architectures that are very difficult to test, maintain, and deploy.

Pattern Example

To illustrate how the layered architecture works, consider a request from a business user to retrieve customer information for a particular individual as illustrated in Figure 1-4 . The black arrows show the request flowing down to the database to retrieve the customer data, and the red arrows show the response flowing back up to the screen to display the data. In this example, the customer information consists of both customer data and order data (orders placed by the customer).  

The customer screen is responsible for accepting the request and displaying the customer information. It does not know where the data is, how it is retrieved, or how many database tables must be queries to get the data. Once the customer screen receives a request to get customer information for a particular individual, it then forwards that request onto the customer delegate module. This module is responsible for knowing which modules in the business layer can process that request and also how to get to that module and what data it needs (the contract). The customer object in the business layer is responsible for aggregating all of the information needed by the business request (in this case to get customer information). This module calls out to the  customer dao  (data access object) module in the persistence layer to get customer data, and also the order dao module to get order information. These modules in turn execute SQL statements to retrieve the corresponding data and pass it back up to the customer object in the business layer. Once the customer object receives the data, it aggregates the data and passes that information back up to the customer delegate, which then passes that data to the customer screen to be presented to the user.      

Figure 1-4. Layered architecture example

From a technology perspective, there are literally dozens of ways these modules can be implemented. For example, in the Java platform, the customer screen can be a (JSF) Java Server Faces screen coupled with the customer delegate as the managed bean component. The customer object in the business layer can be a local Spring bean or a remote EJB3 bean. The data access objects illustrated in the previous example can be implemented as simple POJO’s (Plain Old Java Objects), MyBatis XML Mapper files, or even objects encapsulating raw JDBC calls or Hibernate queries. From a Microsoft platform perspective, the customer screen can be an ASP (active server pages) module using the .NET framework to access C# modules in the business layer, with the customer and order data access modules implemented as ADO (ActiveX Data Objects). 

Considerations

The layered architecture pattern is a solid general-purpose pattern, making it a good starting point for most applications, particularly when you are not sure what architecture pattern is best suited for your application. However, there are a couple of things to consider from an architecture standpoint when choosing this pattern.

The first thing to watch out for is what is known as the architecture sinkhole anti-pattern . This anti-pattern describes the situation where requests flow through multiple layers of the architecture as simple pass-through processing with little or no logic performed within each layer. For example, assume the presentation layer responds to a request from the user to retrieve customer data. The presentation layer passes the request to the business layer, which simply passes the request to the persistence layer, which then makes a simple SQL call to the database layer to retrieve the customer data. The data is then passed all the way back up the stack with no additional processing or logic to aggregate, calculate, or transform the data. 

Every layered architecture will have at least some scenarios that fall into the architecture sinkhole anti-pattern. The key, however, is to analyze the percentage of requests that fall into this category. The 80-20 rule is usually a good practice to follow to determine whether or not you are experiencing the architecture sinkhole anti-pattern. It is typical to have around 20 percent of the requests as simple pass-through processing and 80 percent of the requests having some business logic associated with the request. However, if you find that this ratio is reversed and a majority of your requests are simple pass-through processing, you might want to consider making some of the architecture layers open, keeping in mind that it will be more difficult to control change due to the lack of layer isolation. 

Another consideration with the layered architecture pattern is that it tends to lend itself toward monolithic applications, even if you split the presentation layer and business layers into separate deployable units. While this may not be a concern for some applications, it does pose some potential issues in terms of deployment, general robustness and reliability, performance, and scalability.   

Pattern Analysis

The following table contains a rating and analysis of the common architecture characteristics for the layered architecture pattern. The rating for each characteristic is based on the natural tendency for that characteristic as a capability based on a typical implementation of the pattern, as well as what the pattern is generally known for. For a side-by-side comparison of how this pattern relates to other patterns in this report, please refer to  Appendix A  at the end of this report.

Get Software Architecture Patterns now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Don’t leave empty-handed

Get Mark Richards’s Software Architecture Patterns ebook to better understand how to design components—and how they should interact.

It’s yours, free.

Check it out now on O’Reilly

Dive in for free with a 10-day trial of the O’Reilly learning platform—then explore all the other resources our members count on to build skills and solve problems every day.

Computer Network

• Operating Systems
• Computer Fundamentals
• Interview Q

Physical Layer

Data link layer, network layer, routing algorithm, transport layer, application layer, application protocols, network security.

Interview Questions

• Send your Feedback to [email protected]

Help Others, Please Share

Learn Latest Tutorials

Transact-SQL

Reinforcement Learning

R Programming

React Native

Python Design Patterns

Python Pillow

Python Turtle

Preparation

Verbal Ability

Company Questions

Trending Technologies

Artificial Intelligence

Cloud Computing

Data Science

Machine Learning

B.Tech / MCA

Data Structures

Operating System

Compiler Design

Computer Organization

Discrete Mathematics

Ethical Hacking

Computer Graphics

Software Engineering

Web Technology

Cyber Security

C Programming

Control System

Data Mining

Data Warehouse

Three-tier architecture is a well-established software application architecture that organizes applications into three logical and physical computing tiers: the presentation tier, or user interface; the application tier, where data is processed; and the data tier, where application data is stored and managed.

The chief benefit of three-tier architecture is that because each tier runs on its own infrastructure, each tier can be developed simultaneously by a separate development team. And can be updated or scaled as needed without impacting the other tiers.

For decades three-tier architecture was the prevailing architecture for client-server applications. Today, most three-tier applications are targets for modernization that uses cloud-native technologies such as containers and microservices and for migration to the cloud.

Connect and integrate your systems to prepare your infrastructure for AI.

Register for the guide on app modernization

Presentation tier

The presentation tier is the user interface and communication layer of the application, where the end user interacts with the application. Its main purpose is to display information to and collect information from the user. This top-level tier can run on a web browser, as desktop application, or a graphical user interface (GUI), for example. Web presentation tiers are developed by using HTML, CSS, and JavaScript. Desktop applications can be written in various languages depending on the platform.

Application tier

The application tier, also known as the logic tier or middle tier, is the heart of the application. In this tier, information that is collected in the presentation tier is processed - sometimes against other information in the data tier - using business logic, a specific set of business rules. The application tier can also add, delete, or modify data in the data tier. 

The application tier is typically developed by using Python, Java, Perl, PHP or Ruby, and communicates with the data tier by using  API  calls. 

The data tier, sometimes called database tier, data access tier or back-end, is where the information that is processed by the application is stored and managed. This can be a  relational database management system  such as  PostgreSQL , MySQL, MariaDB, Oracle, Db2, Informix or Microsoft SQL Server, or in a  NoSQL  Database server such as Cassandra,  CouchDB , or  MongoDB . 

In a three-tier application, all communication goes through the application tier. The presentation tier and the data tier cannot communicate directly with one another.

Tier versus layer

In discussions of three-tier architecture,  layer  is often used interchangeably – and mistakenly – for  tier , as in 'presentation layer' or 'business logic layer'. 

They aren't the same. A 'layer' refers to a functional division of the software, but a 'tier' refers to a functional division of the software that runs on infrastructure separate from the other divisions. The Contacts app on your phone, for example, is a  three - layer  application, but a  single-tier  application, because all three layers run on your phone.

The difference is important because layers can't offer the same benefits as tiers.

Again, the chief benefit of three-tier architecture is its logical and physical separation of functionality. Each tier can run on a separate operating system and server platform - for example, web server, application server, database server - that best fits its functional requirements. And each tier runs on at least one dedicated server hardware or virtual server, so the services of each tier can be customized and optimized without impacting the other tiers. 

Other benefits (compared to single- or two-tier architecture) include:

• Faster development : Because each tier can be developed simultaneously by different teams, an organization can bring the application to market faster. And programmers can use the latest and best languages and tools for each tier.
• Improved scalability : Any tier can be scaled independently of the others as needed.
• Improved reliability : An outage in one tier is less likely to impact the availability or performance of the other tiers.
• Improved security : Because the presentation tier and data tier can't communicate directly, a well-designed application tier can function as an internal firewall, preventing SQL injections and other malicious exploits.

In web development, the tiers have different names but perform similar functions:

• The web server  is the presentation tier and provides the user interface. This is usually a web page or website, such as an ecommerce site where the user adds products to the shopping cart, adds payment details or creates an account. The content can be static or dynamic, and is developed using HTML, CSS, and JavaScript.
• The application server  corresponds to the middle tier, housing the business logic that is used to process user inputs. To continue the ecommerce example, this is the tier that queries the inventory database to return product availability, or adds details to a customer's profile. This layer often developed using Python, Ruby, or PHP and runs a framework such as Django, Rails, Symphony, or ASP.NET.
• The database server  is the data or backend tier of a web application. It runs on database management software, such as MySQL, Oracle, DB2, or PostgreSQL.

While three-tier architecture is easily the most widely adopted multitier application architecture, there are others that you might encounter in your work or your research.

Two-tier architecture 

Two-tier architecture is the original client-server architecture, consisting of a presentation tier and a data tier; the business logic lives in the presentation tier, the data tier or both. In two-tier architecture the presentation tier - and therefore the end user - has direct access to the data tier, and the business logic is often limited. A simple contact management application, where users can enter and retrieve contact data, is an example of a two-tier application. 

N-tier architecture

N-tier architecture - also called or multitier architecture - refers to  any  application architecture with more than one tier. But applications with more than three layers are rare because extra layers offer few benefits and can make the application slower, harder to manage and more expensive to run. As a result, n-tier architecture and multitier architecture are usually synonyms for three-tier architecture.

Move to cloud faster with IBM Cloud Pak solutions running on Red Hat OpenShift software—integrated, open, containerized solutions certified by IBM®.

Seamlessly modernize your VMware workloads and applications with IBM Cloud.

Modernize, build new apps, reduce costs, and maximize ROI.

IBM Consulting® application modernization services, which are powered by IBM Consulting Cloud Accelerator, offers skills, methods, tools, and initiatives that help determine the right strategy based on your portfolio. To modernize and containerize legacy system applications and accelerate the time-to-value of hybrid cloud environments. 

Discover what application modernization is, the common benefits and challenges, and how to get started.

Learn about how relational databases work and how they compare to other data storage options.

Explore cloud native applications and how they drive innovation and speed within your enterprise.

Modernize your legacy three-tier applications on your journey to cloud. Whether you need assistance with strategy, processes, or capabilities—or want full-service attention—IBM can help. Start using containerized middleware that can run in any cloud—all bundled in IBM Cloud Paks.