The plaintext data at the source is encrypted into ciphertext (unreadable format), then it is sent to the receiver, where the ciphertext is decrypted into plaintext. Now, if the hacker tries to hack the data, the hacker receives an encrypted, unreadable form, and if the hacker tries to send modified data, the receiver can detect the modification during decryption; thereby, the data remains safe. If the file size is large, it becomes difficult to transmit the large file over the network. File size can be decreased by compressing the file for easy transmission of data. Compression is the method of diminishing the size of a file to transmit data easily in less time. When the compressed data reaches the receiver, the data is reconstructed back to the original size, and this process is called decompression.
The presentation layer in the OSI model is classified into two sublayers:
This sublayer offers services to layer-7, i.e., the application layer, and requests services from layer-5, i.e., the session layer. It supports various application services, such as Reliable Transfer Service Element (RTSE), Remote Operation Service Element (ROSE), Association Control Service Element (ACSE), and Commitment Concurrency and Recovery (CCR). This sublayer offers application-specific protocols, such as Message Oriented Text Interchange Standard (MOTIS), Remote Database Access (RDA), File Transfer Access and Manager (FTAM), Common Management Information Protocol (CMIP), Virtual Terminal (VT), Distributed Transaction Processing (DTP), Job Transfer and Manipulation (JTM), and others. It is a presentation layer protocol in the OSI model, which was formed by Citrix Systems. It is used for transferring data from server to client. It is a very thin protocol as it does not require much overhead in order to transmit data from the server over to the client. It is well-optimized for the WAN. It is the protocol that is used to implement the presentation layer of the OSI model. It provides different kinds of data representation, such as images, video, audio, numbers, etc. It is used for Microsoft Remote Procedure Call (Microsoft RPC) and Distributed Computing Environment (DCE) / Remote Procedure Calls (RPC). It is a communication protocol that was specifically designed for macOS by Apple, Inc. It provides file services for Classic Mac OS and macOS. This protocol is used to share files over the network. It is a protocol that is associated with the client-server operating system. The user can access the directory, print, message, file, clock synchronization, etc., with the help of this protocol. It supports many platforms, such as Linux, Classic Mac OS, Windows NT, Mac OS X, and Microsoft Windows. It is a telecommunications equipment that splits a stream of data into separate packets and formats packet headers for asynchronous communication on X.25 networks. It receives packets from the network and converts them into a stream of data. The PAD provides many asynchronous terminal connectivities to a host computer. It is a computer network protocol that is used to transfer data between two systems. It was first published in 1987. XDR is used by various systems such as NDMP, Network File System, NetCDF, ZFS, Open Network Computer Remote Procedure Call, and others. It is a protocol that offers ISO presentation services over TCP/IP based networks. This protocol explains an approach to provide stream-line support for OSI over TCP/IP based networks.
Latest Courses
We provides tutorials and interview questions of all technology like java tutorial, android, java frameworks
Contact info
G-13, 2nd Floor, Sec-3, Noida, UP, 201301, India
[email protected] .
Online Compiler
Application Architecture Guide - Chapter 10 - Presentation Layer Guidelines
Note - The patterns & practices Microsoft Application Architecture Guide, 2nd Edition is now live at http://msdn.microsoft.com/en-us/library/dd673617.aspx .
- J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
- 1 Objectives
- 3 Presentation Layer Components
- 5 Design Considerations
- 6 Presentation Layer Frame
- 8 Composition
- 9 Exception Management
- 12 Navigation
- 13 Presentation Entities
- 14 Request Processing
- 15 User Experience
- 16 UI Components
- 17 UI Process Components
- 18 Validation
- 19 Pattern Map
- 20 Pattern Descriptions
- 21.1 Mobile Applications
- 21.2 Rich Client Applications
- 21.3 Rich Internet Applications (RIA)
- 21.4 Web Applications
- 22 patterns & practices Solution Assets
- 23 Additional Resources
- Understand how the presentation layer fits into typical application architecture.
- Understand the components of the presentation layer.
- Learn the steps for designing the presentation layer.
- Learn the common issues faced while designing the presentation layer.
- Learn the key guidelines for designing the presentation layer.
- Learn the key patterns and technology considerations for designing the presentation layer.
The presentation layer contains the components that implement and display the user interface and manage user interaction. This layer includes controls for user input and display, in addition to components that organize user interaction. Figure 1 shows how the presentation layer fits into a common application architecture.
Figure 1 A typical application showing the presentation layer and the components it may contain
Presentation Layer Components
- User interface (UI) components . User interface components provide a way for users to interact with the application. They render and format data for users. They also acquire and validate data input by the user.
- User process components . User process components synchronize and orchestrate user interactions. Separate user process components may be useful if you have a complicated UI. Implementing common user interaction patterns as separate user process components allows you to reuse them in multiple UIs.
The following steps describe the process you should adopt when designing the presentation layer for your application. This approach will ensure that you consider all of the relevant factors as you develop your architecture:
- Identify your client type . Choose a client type that satisfies your requirements and adheres to the infrastructure and deployment constraints of your organization. For instance, if your users are on mobile devices and will be intermittently connected to the network, a mobile rich client is probably your best choice.
- Determine how you will present data . Choose the data format for your presentation layer and decide how you will present the data in your UI.
- Determine your data-validation strategy . Use data-validation techniques to protect your system from untrusted input.
- Determine your business logic strategy . Factor out your business logic to decouple it from your presentation layer code.
- Determine your strategy for communication with other layers . If your application has multiple layers, such as a data access layer and a business layer, determine a strategy for communication between your presentation layer and other layers.
Design Considerations
There are several key factors that you should consider when designing your presentation layer. Use the following principles to ensure that your design meets the requirements for your application, and follows best practices:
- Choose the appropriate UI technology. Determine if you will implement a rich (smart) client, a Web client, or a rich Internet application (RIA). Base your decision on application requirements, and on organizational and infrastructure constraints.
- Use the relevant patterns. Review the presentation layer patterns for proven solutions to common presentation problems.
- Design for separation of concerns. Use dedicated UI components that focus on rendering and display. Use dedicated presentation entities to manage the data required to present your views. Use dedicated UI process components to manage the processing of user interaction.
- Consider human interface guidelines. Review your organization’s guidelines for UI design. Review established UI guidelines based on the client type and technologies that you have chosen.
- Adhere to user-driven design principles. Before designing your presentation layer, understand your customer. Use surveys, usability studies, and interviews to determine the best presentation design to meet your customer’s requirements.
Presentation Layer Frame
There are several common issues that you must consider as your develop your design. These issues can be categorized into specific areas of the design. The following table lists the common issues for each category where mistakes are most often made.
Table 1 Presentation Layer Frame
| |
| * Caching volatile data. |
| * Failing to consider use of patterns and libraries that support dynamic layout and injection of views and presentation at runtime. |
| * Failing to catch unhandled exceptions. |
| * Failing to design for intuitive use, or implementing overly complex interfaces. |
| * Using an inappropriate layout style for Web pages. |
| * Inconsistent navigation. |
| * Defining entities that are not necessary. |
| * Blocking the UI during long-running requests. |
| * Displaying unhelpful error messages. |
| * Creating custom components that are not necessary. |
| * Implementing UI process components when not necessary. |
| * Failing to validate all input. |
Caching is one of the best mechanisms you can use to improve application performance and UI responsiveness. Use data caching to optimize data lookups and avoid network round trips. Cache the results of expensive or repetitive processes to avoid unnecessary duplicate processing.
Consider the following guidelines when designing your caching strategy:
- Do not cache volatile data.
- Consider using ready-to-use cache data when working with an in-memory cache. For example, use a specific object instead of caching raw database data.
- Do not cache sensitive data unless you encrypt it.
- If your application is deployed in Web farm, avoid using local caches that need to be synchronized; instead, consider using a transactional resource manager such as Microsoft SQL Server® or a product that supports distributed caching.
- Do not depend on data still being in your cache. It may have been removed.
Composition
Consider whether your application will be easier to develop and maintain if the presentation layer uses independent modules and views that are easily composed at run time. Composition patterns support the creation of views and the presentation layout at run time. These patterns also help to minimize code and library dependencies that would otherwise force recompilation and redeployment of a module when the dependencies change. Composition patterns help you to implement sharing, reuse, and replacement of presentation logic and views.
Consider the following guidelines when designing your composition strategy:
- Avoid using dynamic layouts. They can be difficult to load and maintain.
- Be careful with dependencies between components. For example, use abstraction patterns when possible to avoid issues with maintainability.
- Consider creating templates with placeholders. For example, use the Template View pattern to compose dynamic Web pages in order to ensure reuse and consistency.
- Consider composing views from reusable modular parts. For example, use the Composite View pattern to build a view from modular, atomic component parts.
- If you need to allow communication between presentation components, consider implementing the Publish/Subscribe pattern. This will lower the coupling between the components and improve testability.
Exception Management
Design a centralized exception-management mechanism for your application that catches and throws exceptions consistently. Pay particular attention to exceptions that propagate across layer or tier boundaries, as well as exceptions that cross trust boundaries. Design for unhandled exceptions so they do not impact application reliability or expose sensitive information.
Consider the following guidelines when designing your exception management strategy:
- Use user-friendly error messages to notify users of errors in the application.
- Avoid exposing sensitive data in error pages, error messages, log files, and audit files.
- Design a global exception handler that displays a global error page or an error message for all unhandled exceptions.
- Differentiate between system exceptions and business errors. In the case of business errors, display a user-friendly error message and allow the user to retry the operation. In the case of system exceptions, check to see if the exception was caused by issues such as system or database failure, display a user-friendly error message, and log the error message, which will help in troubleshooting.
- Avoid using exceptions to control application logic.
Design a user input strategy based on your application input requirements. For maximum usability, follow the established guidelines defined in your organization, and the many established industry usability guidelines based on years of user research into input design and mechanisms.
Consider the following guidelines when designing your input collection strategy:
- Use forms-based input controls for normal data-collection tasks.
- Use a document-based input mechanism for collecting input in Microsoft Office–style documents.
- Implement a wizard-based approach for more complex data collection tasks, or for input that requires a workflow.
- Design to support localization by avoiding hard-coded strings and using external resources for text and layout.
- Consider accessibility in your design. You should consider users with disabilities when designing your input strategy; for example, implement text-to-speech software for blind users, or enlarge text and images for users with poor sight. Support keyboard-only scenarios where possible for users who cannot manipulate a pointing device.
Design your UI layout so that the layout mechanism itself is separate from the individual UI components and UI process components. When choosing a layout strategy, consider whether you will have a separate team of designers building the layout, or whether the development team will create the UI. If designers will be creating the UI, choose a layout approach that does not require code or the use of development-focused tools.
Consider the following guidelines when designing your layout strategy:
- Use templates to provide a common look and feel to all of the UI screens.
- Use a common look and feel for all elements of your UI to maximize accessibility and ease of use.
- Consider device-dependent input, such as touch screens, ink, or speech, in your layout. For example, with touch-screen input you will typically use larger buttons with more spacing between them than you would with mouse or keyboard inputs.
- When building a Web application, consider using Cascading Style Sheets (CSS) for layout. This will improve rendering performance and maintainability.
- Use design patterns, such as Model-View-Presenter (MVP), to separate the layout design from interface processing.
Design your navigation strategy so that users can navigate easily through your screens or pages, and so that you can separate navigation from presentation and UI processing. Ensure that you display navigation links and controls in a consistent way throughout your application to reduce user confusion and hide application complexity.
Consider the following guidelines when designing your navigation strategy:
- Use well-known design patterns to decouple the UI from the navigation logic where this logic is complex.
- Design toolbars and menus to help users find functionality provided by the UI.
- Consider using wizards to implement navigation between forms in a predictable way.
- Determine how you will preserve navigation state if the application must preserve this state between sessions.
- Consider using the Command Pattern to handle common actions from multiple sources.
Presentation Entities
Use presentation entities to store the data you will use in your presentation layer to manage your views. Presentation entities are not always necessary; use them only if your datasets are sufficiently large and complex to require separate storage from the UI controls.
Consider the following guidelines when designing presentation entities:
- Determine if you require presentation entities. Typically, you may require presentation entities only if the data or the format to be displayed is specific to the presentation layer.
- If you are working with data-bound controls, consider using custom objects, collections, or datasets as your presentation entity format.
- If you want to map data directly to business entities, use a custom class for your presentation entities.
- Do not add business logic to presentation entities.
- If you need to perform data type validation, consider adding it in your presentation entities.
Request Processing
Design your request processing with user responsiveness in mind, as well as code maintainability and testability.
Consider the following guidelines when designing request processing:
- Use asynchronous operations or worker threads to avoid blocking the UI for long-running actions.
- Avoid mixing your UI processing and rendering logic.
- Consider using the Passive View pattern (a variant of MVP) for interfaces that do not manage a lot of data.
- Consider using the Supervising Controller pattern (a variant of MVP) for interfaces that manage large amounts of data.
User Experience
Good user experience can make the difference between a usable and unusable application. Carry out usability studies, surveys, and interviews to understand what users require and expect from your application, and design with these results in mind.
Consider the following guidelines when designing for user experience:
- When developing a rich Internet application (RIA), avoid synchronous processing where possible.
- When developing a Web application, consider using Asynchronous JavaScript and XML (AJAX) to improve responsiveness and to reduce post backs and page reloads.
- Do not design overloaded or overly complex interfaces. Provide a clear path through the application for each key user scenario.
- Design to support user personalization, localization, and accessibility.
- Design for user empowerment. Allow the user to control how he or she interacts with the application, and how it displays data to them.
UI Components
UI components are the controls and components used to display information to the user and accept user input. Be careful not to create custom controls unless it is necessary for specialized display or data collection.
Consider the following guidelines when designing UI components:
- Take advantage of the data-binding features of the controls you use in the UI.
- Create custom controls or use third-party controls only for specialized display and data-collection tasks.
- When creating custom controls, extend existing controls if possible instead of creating a new control.
- Consider implementing designer support for custom controls to make it easier to develop with them.
- Consider maintaining the state of controls as the user interacts with the application instead of reloading controls with each action.
UI Process Components
UI process components synchronize and orchestrate user interactions. UI processing components are not always necessary; create them only if you need to perform significant processing in the presentation layer that must be separated from the UI controls. Be careful not to mix business and display logic within the process components; they should be focused on organizing user interactions with your UI.
Consider the following guidelines when designing UI processing components:
- Do not create UI process components unless you need them.
- If your UI requires complex processing or needs to talk to other layers, use UI process components to decouple this processing from the UI.
- Consider dividing UI processing into three distinct roles: Model, View, and Controller/Presenter, by using the MVC or MVP pattern.
- Avoid business rules, with the exception of input and data validation, in UI processing components.
- Consider using abstraction patterns, such as dependency inversion, when UI processing behavior needs to change based on the run-time environment.
- Where the UI requires complex workflow support, create separate workflow components that use a workflow system such as Windows Workflow or a custom mechanism.
Designing an effective input and data-validation strategy is critical to the security of your application. Determine the validation rules for user input as well as for business rules that exist in the presentation layer.
Consider the following guidelines when designing your input and data validation strategy:
- Validate all input data on the client side where possible to improve interactivity and reduce errors caused by invalid data.
- Do not rely on client-side validation only. Always use server-side validation to constrain input for security purposes and to make security-related decisions.
- Design your validation strategy to constrain, reject, and sanitize malicious input.
- Use the built-in validation controls where possible, when working with .NET Framework.
- In Web applications, consider using AJAX to provide real-time validation.
Pattern Map
Key patterns are organized by key categories, as detailed in the Presentation Layer Frame in the following table. Consider using these patterns when making design decisions for each category.
Table 2 Pattern Map
| |
| * Cache Dependency |
| * Composite View |
| * Exception Shielding |
| * Template View |
| * Front Controller |
| * Entity Translator |
| * Asynchronous Callback |
| * Model-View-Controller (MVC) |
- For more information on the Page Cache pattern, see “Enterprise Solution Patterns Using Microsoft .NET” at http://msdn.microsoft.com/en-us/library/ms998469.aspx
- For more information on the Model-View-Controller (MVC), Page Controller, Front Controller, Template View, Transform View, and Two-Step View patterns, see “Patterns of Enterprise Application Architecture (P of EAA)” at http://martinfowler.com/eaaCatalog/
- For more information on the Composite View, Supervising Controller, and Presentation Model patterns, see “Patterns in the Composite Application Library” at http://msdn.microsoft.com/en-us/library/cc707841.aspx
- For more information on the Chain of responsibility and Command pattern, see “data & object factory” at http://www.dofactory.com/Patterns/Patterns.aspx
- For more information on the Asynchronous Callback pattern, see “Creating a Simplified Asynchronous Call Pattern for Windows Forms Applications” at http://msdn.microsoft.com/en-us/library/ms996483.aspx
- For more information on the Exception Shielding and Entity Translator patterns, see “Useful Patterns for Services” at http://msdn.microsoft.com/en-us/library/cc304800.aspx
Pattern Descriptions
- Asynchronous Callback. Execute long-running tasks on a separate thread that executes in the background, and provide a function for the thread to call back into when the task is complete.
- Cache Dependency. Use external information to determine the state of data stored in a cache.
- Chain of Responsibility. Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.
- Composite View . Combine individual views into a composite representation.
- Command Pattern. Encapsulate request processing in a separate command object with a common execution interface.
- Entity Translator. An object that transforms message data types into business types for requests, and reverses the transformation for responses.
- Exception Shielding. Prevent a service from exposing information about its internal implementation when an exception occurs.
- Front Controller . Consolidate request handling by channeling all requests through a single handler object, which can be modified at run time with decorators.
- Model-View-Controller . Separate the UI code into three separate units: Model (data), View (interface), and Presenter (processing logic), with a focus on the View. Two variations on this pattern include Passive View and Supervising Controller, which define how the View interacts with the Model.
- Page Cache. Improve the response time for dynamic Web pages that are accessed frequently but change less often and consume a large amount of system resources to construct.
- Page Controller . Accept input from the request and handle it for a specific page or action on a Web site.
- Passive View . Reduce the view to the absolute minimum by allowing the controller to process user input and maintain the responsibility for updating the view.
- Presentation Model . Move all view logic and state out of the view, and render the view through data-binding and templates.
- Supervising Controller . A variation of the MVC pattern in which the controller handles complex logic, in particular coordinating between views, but the view is responsible for simple view-specific logic.
- Template View . Implement a common template view, and derive or construct views using this template view.
- Transform View . Transform the data passed to the presentation tier into HTML for display in the UI.
- Two-Step View . Transform the model data into a logical presentation without any specific formatting, and then convert that logical presentation to add the actual formatting required.
Technology Considerations
The following guidelines will help you to choose an appropriate implementation technology. The guidelines also contain suggestions for common patterns that are useful for specific types of application and technology.
Mobile Applications
Consider the following guidelines when designing a mobile application:
- If you want to build full-featured connected, occasionally connected, and disconnected executable applications that run on a wide range of Microsoft Windows®–based devices, consider using the Microsoft Windows Compact Framework.
- If you want to build connected applications that require Wireless Application Protocol (WAP), compact HTML (cHTML), or similar rendering formats, consider using ASP.NET Mobile Forms and Mobile Controls.
- If you want to build applications that support rich media and interactivity, consider using Microsoft Silverlight® for Mobile.
Rich Client Applications
Consider the following guidelines when designing a rich client application:
- If you want to build applications with good performance and interactivity, and have design support in Microsoft Visual Studio®, consider using Windows Forms.
- If you want to build applications that fully support rich media and graphics, consider using Windows Presentation Foundation (WPF).
- If you want to build applications that are downloaded from a Web server and then execute on the client, consider using XAML Browser Applications (XBAP).
- If you want to build applications that are predominantly document-based, or are used for reporting, consider designing a Microsoft Office Business Application.
- If you decide to use Windows Forms and you are designing composite interfaces, consider using the Smart Client Software Factory.
- If you decide to use WPF and you are designing composite interfaces, consider using the Composite Application Guidance for WPF.
- If you decide to use WPF, consider using the Presentation Model (Model-View-ViewModel) pattern.
- If you decide to use WPF, consider using WPF Commands to communicate between your View and your Presenter or ViewModel.
- If you decide to use WPF, consider implementing the Presentation Model pattern by using DataTemplates over User Controls to give designers more control.
Rich Internet Applications (RIA)
Consider the following guidelines when designing an RIA:
- If you want to build browser-based, connected applications that have broad cross-platform reach, are highly graphical, and support rich media and presentation features, consider using Silverlight.
- If you decide to use Silverlight, consider using the Presentation Model (Model-View-ViewModel) pattern.
Web Applications
Consider the following guidelines when designing a Web application:
- If you want to build applications that are accessed through a Web browser or specialist user agent, consider using ASP.NET.
- If you want to build applications that provide increased interactivity and background processing, with fewer page reloads, consider using ASP.NET with AJAX.
- If you want to build applications that include islands of rich media content and interactivity, consider using ASP.NET with Silverlight controls.
- If you are using ASP.NET and want to implement a control-centric model with separate controllers and improved testability, consider using the ASP.NET MVC Framework.
- If you are using ASP.NET, consider using master pages to simplify development and implement a consistent UI across all pages.
patterns & practices Solution Assets
- Web Client Software Factory at http://msdn.microsoft.com/en-us/library/bb264518.aspx
- Smart Client Software Factory at http://msdn.microsoft.com/en-us/library/aa480482.aspx
- Composite Application Guidance for WPF at http://msdn.microsoft.com/en-us/library/cc707819.aspx
- Smart Client - Composite UI Application Block at http://msdn.microsoft.com/en-us/library/aa480450.aspx
Additional Resources
- For more information, see Microsoft Inductive User Interface Guidelines at http://msdn.microsoft.com/en-us/library/ms997506.aspx .
- For more information, see User Interface Control Guidelines at http://msdn.microsoft.com/en-us/library/bb158625.aspx .
- For more information, see User Interface Text Guidelines at http://msdn.microsoft.com/en-us/library/bb158574.aspx .
- For more information, see Design and Implementation Guidelines for Web Clients at http://msdn.microsoft.com/en-us/library/ms978631.aspx .
- For more information, see Web Presentation Patterns at http://msdn.microsoft.com/en-us/library/ms998516.aspx .
Navigation menu
Page actions.
Personal tools
- Community portal
- Current events
- Recent changes
- Random page
- What links here
- Related changes
- Special pages
- Printable version
- Permanent link
- Page information
- This page was last edited on 22 January 2010, at 07:50.
- Privacy policy
- About Guidance Share
- Disclaimers
IMAGES
VIDEO
COMMENTS
The presentation layer is layer 6 of the 7-layer Open Systems Interconnection (OSI) model. It is used to present data to the application layer (layer 7) in an accurate, well-defined and standardized format. The presentation layer is sometimes called the syntax layer. Techopedia Explains Presentation Layer. The presentation layer is responsible ...
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 presentation layer resides at Layer 6 of the Open Systems Interconnection (OSI) communications model and ensures that communications that pass through it are in the appropriate form for the recipient application. In other words, the presentation layer presents the data in a readable format from an application layer perspective.
The presentation layer ensures the information that the application layer of one system sends out is readable by the application layer of another system. On the sending system it is responsible for conversion to standard, transmittable formats. [7] On the receiving system it is responsible for the translation, formatting, and delivery of ...
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 ...
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. The Presentation Layer is the sixth layer in the OSI model. It sits right above the Session Layer and below the Application Layer. Its main job is to handle how data is presented to the application. In other words, it ensures that the data is in a format that both the sending and receiving systems can understand.
The Presentation Layer, within the OSI (Open Systems Interconnection) model, is the sixth layer. It focuses on the representation of data, ensuring that information exchanged between applications is formatted appropriately for transmission and receipt across a network. This layer handles tasks such as data translation, encryption, compression ...
The presentation layer is a very important layer because it handles encryption, decryption, and the conversion of complex data into flat-byte strings, a format that is easily transmittable. The ...
OSI uses three layers -- application, presentation and session -- to define the functionality of upper layers, while TCP/IP uses only the application layer. OSI uses two separate layers -- physical and data-link -- to define the functionality of the bottom layers, while TCP/IP uses only the link layer.
Understanding the layers of the Open Systems Interconnect (OSI) model can help users conceptualize data communication over a network. Layer 6 in the OSI model - the presentation layer - translates, compresses, and encrypts data across networks. In this article, we'll explain what the presentation layer is, how it works, and its functions and protocols.
Functionalities of the Presentation Layer. Specific functionalities of the presentation layer are as follows: 1. Translation. The processes or running programs in two machines are usually exchanging the information in the form of numbers, character strings and so on before being transmitted. The information should be changed to bitstreams ...
OSI: Layer 6 - Presentation. The presentation layer is the sixth layer (layer 6) of the seven-layer OSI model. The presentation layer is responsible for the delivery and formatting of information to the application layer for further processing or presentation to the user. It relieves the application layer from the responsibility in data ...
The presentation layer is one of the three main layers in object-oriented programming. The three main layers include: Presentation Layer. Business Layer. Data Layer. Now, these three layers are typically related to enterprise web applications. It's a design pattern used to help separate your code out in three distinct areas that (if need be ...
In subject area: Computer Science. The Presentation Layer in the OSI model is defined as the layer that enables interaction between different application layer implementations by translating data formats and languages to facilitate communication. AI generated definition based on: Security for Microsoft Windows System Administrators, 2011.
Here are five main layers in software architecture: 1. Presentation layer. The presentation layer, also called the UI layer, handles the interactions that users have with the software. It's the most visible layer and defines the application's overall look and presentation to the end-users.
In technical speech, the presentation layer is the sixth of seven layers of OSI code that translates data stored in another layer into something a human can interpret. It's the presentation layer that knows to put the right information into the appropriate fields of a customer record, for example: Name, Date of Birth, Address, etc.
The presentation layer is the sixth layer of the Open Systems Interconnection (OSI), model. In computer networking, the OSI model is a concept that describes the transmission of data from one computer to another. Each layer in the model is a packet of protocols, or procedures that govern data transmission, which allow the layer to execute ...
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 officially ...
The presentation layer is the 6 th layer from the bottom in the OSI model. This layer presents the incoming data from the application layer of the sender machine to the receiver machine. It converts one format of data to another format of data if both sender and receiver understand different formats; hence this layer is also called the ...
Overview. The presentation layer contains the components that implement and display the user interface and manage user interaction. This layer includes controls for user input and display, in addition to components that organize user interaction. Figure 1 shows how the presentation layer fits into a common application architecture.
Presentation layer definition. The presentation layer is the sixth layer in the Open System Interconnection (OSI) model. It serves as the data translator for the network — it takes data formats from different sources and presents it to the application layer in an accurate, well-defined, and standardized manner. Real presentation layer functions