Web application architecture: best practices and guides

What Is Network Architecture?

Network architecture is the logical and structural layout of a network. In addition to hardware and physical connections, software, wireless networks and protocols, the medium of data transmission also constitutes the network architecture. Network architecture provides a detailed overview of the whole network, which is used to classify network layers. Organizations use network diagrams to create local area networks, wide-area networks and specific tunnels of communications.

What Is Neural Network Architecture?

Neural network architecture is a type of network design that refers to a network made from individual units, known as neurons. Mimicking the neurons found in a human brain, the neurons can receive input, understand the importance of that input, and then combine multiple inputs into one output value. Activation functions make the output a non-linear combination of all input values.

Note:

A neural network has several rows of neurons, and several neurons in a single row constitute a layer, creating a multi-layer neural network. The first layer is called the input layer, followed by hidden layers and, finally, the last layer is the output layer. Hidden layers are intermediate layers that perform the computations, search for and extract features from the data, and pass on the information to the final output layer.

What Is a Network Architecture Diagram?

A Network Architecture Diagram is the visual representation of the network. The layout of the elements that constitute a network is represented with various symbols and lines. Visual representation is the most intuitive way to process information and understand how network elements are connected. This is helpful when organizations are creating new systems or trying to understand where the problem in the network is. The network diagram is created using various software programs, such as SmartDraw, Creately, Intermapper or SolarWinds NTM.

What Is Zero Trust Network Architecture?

Zero Trust Network Architecture is a model of network where every connection to the system has to be verified. The architecture is implemented when the security of the network is ineffective. With numerous users accessing the data from various locations and devices, security breaches are frequent. Zero Trust Network Architecture aims to reduce unauthorized access to the data within the network. Multiple technologies are used to achieve the necessary security, including multi-factor authentication, encryption, IAM (identity and access management), and file system permissions.

What Is Core Network Architecture?

Core Network Architecture is a 5G network architecture that allows devices to be connected over non-3GPP access technologies. The access network can be any network that’s supported by the device, as long as the network offers IP connectivity. EPC (Evolved Packet Core) also exists for 4G, but 5G offers fewer options for supporting devices with non-3GPP access.

The concept of “trusted” and “untrusted” access is present in Core Network Architecture. An example of untrusted networks are private and public Wi-Fi networks, which usually require a password for an outside device to gain access. After the device has connected to the network and the access is granted, an IP address is assigned to the device within the network.

What is network architecture?

Network architectures set the overarching structure for the way data flows to, from, and between resources. In this context, a “resource” could be something like a file server, a customer relationship management system, or a user device. Designing a network architecture requires the consideration of various aspects, including:

• Logical networks — Logical networks are established by a set of policies that define which resources may connect with each other, how they connect, and any conditions for that access. Manufacturing systems, for instance, may only be limited to managed devices on managed networks. Mail servers, on the other hand, may be accessed by VPN-connected user devices.
• Physical networks — Distinct from the logical structure is the hardware that transports data within company boundaries and interfaces to the internet. This structure guides decisions such as when to segment local area networks and when wireless LANs are appropriate.
• Performance, reliability, and efficiency standards — These standards help IT professionals design cost-effective networks that support business objectives. Clear guidance on latency and bandwidth requirements, for example, lets them address chokepoints such as VPN gateways early in the network design process.
• Security and access control standards — Network architectures balance the accessibility users need with the need to secure proprietary and customer information. To help strike this balance, a network architecture could require that all access control investments support role-based access.

Historically, these aspects of network architecture were inextricably linked. That is less true today thanks to trends such as virtualization, software-as-a-service, and remote access.

• Virtualization — With the rise of virtualization, dedicated hardware appliances like routers and firewalls are no longer necessary. Physical networking equipment can now be replaced with software on virtual appliances and servers in the cloud that deliver the same functionality. A company’s physical network must address a virtualized network architecture’s unique requirements.
• Software-as-a-Service — Companies are turning away from monolithic applications and on-premises licensed client software to use subscription-based cloud services. This decision, however, impacts the degree of integration between a company’s users, private networks, and the internet.
• Remote access — Mobile computing has weakened the idea that employee productivity depended on being in the office. Yet expanding remote access requires changes to networks and security systems.

Что представляют собой слои?

По мере увеличения сложности приложения для эффективного управления им может применяться разбиение по обязанностям и задачам. Такой подход соответствует принципу разделения задач и помогает сохранить организацию расширяющейся базы кода, благодаря чему разработчики могут быстро определять, где именно реализованы определенные функции. Многослойная архитектура имеет также целый ряд других преимуществ.

Благодаря упорядочению кода с помощью слоев общие низкоуровневые функции могут многократно использоваться по всему приложению

Это крайне важно, поскольку такой подход требует меньшего объема кода и, за счет стандартизации приложения на уровне одной реализации, соответствует принципу «Не повторяйся»

В приложениях с многослойной архитектурой могут устанавливаться ограничения на взаимодействие между слоями. Такая архитектура помогает реализовать инкапсуляцию. При изменении или замене слоя будут затронуты только те слои, которые работают непосредственно с ним. Ограничивая зависимости слоев друг от друга, можно уменьшить последствия внесения изменений, в результате чего единичное изменение не будет влиять на все приложение.

Применение слоев (и инкапсуляция) позволяет заметно упростить замену функциональных возможностей в рамках приложения. Например, приложение может изначально использовать собственную базу данных SQL Server для сохраняемости, а впоследствии перейти на стратегию сохранения состояния на основе облака или веб-API. Если в приложении надлежащим образом инкапсулирована реализация сохраняемости на логическом слое, этот слой SQL Server может быть заменен новым, где будет реализовываться тот же открытый интерфейс.

Помимо возможности замены реализаций в связи с последующими изменениями, применение слоев в приложении также позволяет менять реализации в целях тестирования. Вместо написания тестов, которые применяются к слоям реальных данных или пользовательского интерфейса приложения, во время тестирования они заменяются фиктивными реализациями, которые демонстрируют известную реакцию на запросы. Как правило, это значительно упрощает написание тестов и ускоряет их выполнение по сравнению с тестированием в реальной инфраструктуре приложения.

Разделение на логические слои широко распространено и помогает упорядочить код приложений предприятия. Сделать это можно несколькими способами.

Примечание

Слои обеспечивают логический уровень разделения в приложении. Если логика приложения физически распределена между несколькими серверами или процессами, такие раздельные физические целевые объекты развертывания называются уровнями. Таким образом, не только возможно, но и широко распространено развертывание N-слойных приложений на одном уровне.

What Is the Difference Between Software Architecture and Software Design?

If you are new to the process of building web applications, there is a chance that you will confuse the concepts of software architecture and software design. For this reason, we would like to elaborate on the differences between them.

Website development architecture is the result of the first phase of your product development. The documents that describe such an architecture detail things like the high-level components of your system, as well as the connections between them. Within the framework of web app development, digital architecture work involves finding a relevant pattern and identifying other key characteristics of the system components (for example, deciding in favor of NoSQL or SQL).

The issue of software design is raised in the later stages of product development (the code level) once the web application design patterns are already known. Software design is about the direct code writing for the web app architecture components and forming software modules and classes.

Sometimes, at the stage of working on the software design of a new web product, programmers find that they can borrow some parts of the code from open sources and thereby optimize their work. At the same time, an already created web architecture for one product is usually difficult to adapt to a new product.

Web app architecture: components

Web Application Architectures comprises various components that are segregated into two categories of components – user interface components and structural components.

User interface app components

This is a reference to the web pages that have a role that is related to the display, settings and configurations.

It is related the interface/experience, rather than the development, and consequently it deals with display dashboards, configuration settings, notifications, and logs etc.

Structural components

The structural components basically refer to the functionality with which a user interacts, the control and the database storage.

In other words, it has got more to do with the structural aspects of the architecture, as the name suggests. This basically comprises (1) The web browser or client, (2) The web application server and (3) The database server.

The web browser or client permits the users to interact with the functions of the web developed with HTML, CSS, and JavaScript.

The database server offers business logic and relevant information/data that is stored and managed by the server. It stores, retrieves and provides the information.

Поддержка Docker

Проект работает в .NET. Поэтому его можно запускать как в контейнерах Linux, так и в контейнерах Windows

Обратите внимание на то, что для развертывания Docker необходимо использовать тот же тип узла для SQL Server. Контейнеры на основе Linux требуют меньше ресурсов и более предпочтительны

Вы можете использовать Visual Studio 2017, чтобы добавить поддержку Docker в существующее приложение, щелкнув проект в обозревателе решений правой кнопкой мыши и выбрав Добавить>Поддержка Docker. Таким образом вы добавите необходимые файлы и внесете изменения в проект для их использования. В текущем примере эти файлы уже есть.

Файл на уровне решения содержит сведения о том, какие образы необходимо создать и какие контейнеры запустить. Этот файл позволяет использовать команду для запуска нескольких приложений одновременно. В этом случае он запускает только веб-проект. Вы также можете с его помощью настроить зависимости, например отдельный контейнер базы данных.

Файл ссылается на в проекте . С помощью можно указать, какой базовый контейнер будет использоваться и как приложение будет настроено на нем. :

Устранение неполадок с Docker

После запуска контейнерное приложение продолжает работать, пока его не остановят. Используйте команду , чтобы посмотреть, какие контейнеры выполняются. Вы можете остановить выполняющийся контейнер с помощью команды и идентификатора контейнера.

Обратите внимание, что запущенные контейнеры Docker могут быть привязаны к портам, которые в противном случае вы могли бы использовать в среде разработки. При попытке запустить или выполнить отладку приложения через порт, связанный с контейнером Docker, возникнет ошибка с сообщением о том, что сервер не может выполнить привязку к этому порту

Проблемы будет решена, если вы остановите контейнер.

Если вы хотите добавить поддержку Docker в приложение с помощью Visual Studio, убедитесь, что Docker Desktop при этом запущен. Если при запуске мастера средство Docker Desktop не выполняется, мастер будет работать неправильно. Кроме того, мастер проверяет выбранные контейнеры, чтобы правильно реализовать поддержку Docker. Чтобы добавить поддержку контейнеров Windows, необходимо запускать мастер при запущенном инструменте Docker Desktop с настроенными контейнерами Windows. Чтобы добавить поддержку контейнеров Linux, запускайте мастер при запущенном инструменте Docker с настроенными контейнерами Linux.

Другие стили архитектуры веб-приложений

• Web-Queue-Worker. Основными компонентами этой архитектуры являются внешний веб-интерфейс, который обслуживает клиентские запросы, и рабочая роль, которая выполняет ресурсоемкие задачи, длительные рабочие процессы или пакетные задания. Веб-интерфейс взаимодействует с рабочей ролью через очередь сообщений.
• N-уровень. N-уровневая архитектура разделяет приложение на логические и физические уровни.
• Микрослужба. Архитектура микрослужб состоит из коллекции небольших автономных служб. Каждая служба является самодостаточной и должна реализовывать возможности одной компании в ограниченном контексте.

Ссылки — общие архитектуры веб-приложений

• Чистая архитектураhttps://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
• Многослойная архитектураhttps://jeffreypalermo.com/blog/the-onion-architecture-part-1/
• Шаблон репозиторияhttps://deviq.com/repository-pattern/
• Шаблон решения с чистой архитектуройhttps://github.com/ardalis/cleanarchitecture
• Электронная книга по разработке архитектуры микрослужбhttps://aka.ms/MicroservicesEbook
• DDD (предметно-ориентированное проектирование)https://learn.microsoft.com/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/

Business Access Layer

The business layer communicates with the data access layer and the presentation layer logic layer process the actions that make the logical decision and evaluations the main function of this layer is to process the data between surrounding layers.

Our Structure of the project in the Business Access Layer will be like this.

In this layer we will have two folders

• Extensions Method Folder
• And Services Folder

In the business access layer, we have our services that communicate with the surrounding layers like the data layer and Presentation Layer.

Services

Services define the application’s business logic. We develop services that interact with the data layer and move data from the data layer to the presentation layer and from the presentation layer to the data access layer.

Example

Traditional «N-Layer» architecture applications

The most common organization of application logic into layers is shown in Figure 5-2.

Figure 5-2. Typical application layers.

These layers are frequently abbreviated as UI, BLL (Business Logic Layer), and DAL (Data Access Layer). Using this architecture, users make requests through the UI layer, which interacts only with the BLL. The BLL, in turn, can call the DAL for data access requests. The UI layer shouldn’t make any requests to the DAL directly, nor should it interact with persistence directly through other means. Likewise, the BLL should only interact with persistence by going through the DAL. In this way, each layer has its own well-known responsibility.

One disadvantage of this traditional layering approach is that compile-time dependencies run from the top to the bottom. That is, the UI layer depends on the BLL, which depends on the DAL. This means that the BLL, which usually holds the most important logic in the application, is dependent on data access implementation details (and often on the existence of a database). Testing business logic in such an architecture is often difficult, requiring a test database. The dependency inversion principle can be used to address this issue, as you’ll see in the next section.

Figure 5-3 shows an example solution, breaking the application into three projects by responsibility (or layer).

Figure 5-3. A simple monolithic application with three projects.

Although this application uses several projects for organizational purposes, it’s still deployed as a single unit and its clients will interact with it as a single web app. This allows for very simple deployment process. Figure 5-4 shows how such an app might be hosted using Azure.

Figure 5-4. Simple deployment of Azure Web App

As application needs grow, more complex and robust deployment solutions may be required. Figure 5-5 shows an example of a more complex deployment plan that supports additional capabilities.

Figure 5-5. Deploying a web app to an Azure App Service

Internally, this project’s organization into multiple projects based on responsibility improves the maintainability of the application.

This unit can be scaled up or out to take advantage of cloud-based on-demand scalability. Scaling up means adding additional CPU, memory, disk space, or other resources to the server(s) hosting your app. Scaling out means adding additional instances of such servers, whether these are physical servers, virtual machines, or containers. When your app is hosted across multiple instances, a load balancer is used to assign requests to individual app instances.

The simplest approach to scaling a web application in Azure is to configure scaling manually in the application’s App Service Plan. Figure 5-6 shows the appropriate Azure dashboard screen to configure how many instances are serving an app.

Figure 5-6. App Service Plan scaling in Azure.

Models of web app components

The model of the web app will depend on the total number of servers and databases used for the design. Below are the models of web app components:

One web server (with database)

One web server with a single database web app component model uses a single server and database. A web app that builds on such a model will go down as soon as the server goes down. That’s why it is unreliable.

Generally, this model is used for running test projects and intending to learn and understand the fundamentals of the web application.

Two+ web servers, one database

In this web application component model, the webserver doesn’t store any data. When the web-server gets information from a client, it writes it to the database after processing. Both these things are managed outside of the server, which is known as stateless architecture.

At least two web servers are needed for this component model to avoid failure. So if one of the web servers goes down, the other one will come to action. All requests will be automatically redirected to the new server so that the web app will continue execution. Hence, reliability is better compared to a single server.

Two+ web servers, two+ databases

This model is the most efficient one. The two servers or multi-server model gives two options to its user where they can store the whole data into employed databases or they can disperse it through these databases.

To store the whole data, the user just needs two databases. But in the case of dispersement, However, the most common thing in both these cases is DBMS normalization. Also, it is advisable to use more than 4 or 5 servers or both to install load balancers.

Традиционные приложения с N-слойной архитектурой

Общепринятая организация логики приложения по слоям показана на рис. 5-2.

Рис. 5-2. Слои типового приложения.

Как правило, в приложении определяются слои пользовательского интерфейса, бизнес-логики и доступа к данным. В рамках такой архитектуры пользователи выполняют запросы через слой пользовательского интерфейса, который взаимодействует только со слоем бизнес-логики. Слой бизнес-логики, в свою очередь, может вызывать слой доступа к данным для обработки запросов. Слой пользовательского интерфейса не должен выполнять запросы напрямую к слою доступа к данным и какими-либо другими способами напрямую взаимодействовать с функциями сохраняемости. Аналогичным образом, слой бизнес-логики должен взаимодействовать с функциями сохраняемости только через слой доступа к данным. Таким образом, для каждого слоя четко определена своя обязанность.

Одним из недостатков традиционного многослойного подхода является то, что обработка зависимостей во время компиляции осуществляется сверху вниз. Это значит, что слой пользовательского интерфейса зависит от слоя бизнес-логики, который, в свою очередь, зависит от слоя доступа к данным. Это значит, что слой бизнес-логики, который обычно содержит ключевые функции приложения, зависит от деталей реализации доступа к данным (и зачастую от наличия самой базы данных). Тестирование бизнес-логики в такой архитектуре зачастую затруднено и требует наличия тестовой базы данных. Для решения этой проблемы может применяться принцип инверсии зависимостей, как описывается в следующем разделе.

На рис. 5-3 показан пример решения, в котором приложение разделено на три проекта (или слоя) в соответствии с определенными обязанностями.

Рис. 5-3. Простое монолитное приложение, состоящее из трех проектов.

Несмотря на то, что в целях упорядочения в этом приложении используется несколько проектов, оно по-прежнему развертывается как единый элемент, и его клиенты взаимодействуют с ним как с одним веб-приложением. Это позволяет реализовать крайне простой процесс развертывания. На рис. 5-4 показано, как такое приложение можно разместить с использованием Azure.

Рис. 5-4. Простое развертывание веб-приложения Azure

По мере развития приложения могут потребоваться более сложные и надежные решения для развертывания. На рис. 5-5 показан пример более сложного плана развертывания, который поддерживает дополнительные возможности.

Рис. 5-5. Развертывание веб-приложения в службе приложений Azure

Разбиение этого проекта на несколько проектов на основе обязанностей позволяет повысить удобство поддержки приложения.

Такой элемент поддерживает вертикальное и горизонтальное масштабирование, что позволяет использовать преимущества облачного масштабирования по запросу. Под вертикальным масштабированием понимается увеличение числа ЦП, объема памяти, места на диске и других ресурсов на серверах, где размещается приложение. Горизонтальное масштабирование заключается в добавлении дополнительных экземпляров таких физических серверов, виртуальных машин или контейнеров. Если приложение размещается на нескольких экземплярах, для распределения запросов между экземплярами приложения используется система балансировки нагрузки.

Самый простой подход к масштабированию веб-приложения в Azure заключается в ручной настройке масштабирования в плане службы приложений для приложения. На рис. 5-6 показан экран панели мониторинга Azure, предназначенный для настройки числа экземпляров, обслуживающих приложение.

Рис. 5-6. Масштабирование плана службы приложений в Azure.

Which type of network architecture makes sense for your organization?

Nobody will ever develop the perfect network architecture, and architectural needs change as organizations and technology evolve. Your organization’s context will determine your optimal network design. Some of the factors you must consider include:

• Business stage — Unlike startups, established businesses cannot take clean sheet approaches. Network architectures must factor in legacy systems and business processes.
• User base — The number of users, the mix of employees and contractors, and the degree of remote working profoundly affect network architecture.
• Regulations — Defense contractors and banks have stringent requirements for data security. Less regulated industries must still consider GDPR and other data protection rules.

Сервисы

Веб-приложениям необходимы аутентификация, обмен электронными письмами, логирование, мониторинг, машинное обучение, система платежей и другие сервисы. Кроме того, им нужны службы, связанные с разработкой, проектированием и развёртыванием, такие как хостинг репозиториев, непрерывная интеграция/доставка (CI/CD), база данных, хостинг приложений, поиск/индексирование и тому подобное. Ключевые требования для этих сервисов можно реализовать с помощью многих опенсорсных фреймворков. Но всё равно понадобится инфраструктура, чтобы установить и использовать эти сервисы.

Многие компании и стартапы, работающие по модели «как услуга» (as-a-service), предоставляют почти все эти облачные сервисы для веб-разработки. Кроме того, некоторые крупные технологические компании создали собственные экосистемы для разработки, в которых объединили множество облачных сервисов.

Why Does Web Architecture Matter?

As we already know, web application architecture design is the first stage of software development, and web architecture, in turn, is the backbone of your web app. So what makes digital product architecture so important?

First, the web architecture is literally the foundation onto which you put all the other product components. If this foundation is solid and stable, further work on the product will be time- and cost-effective. If you make mistakes at this critical stage, all the other stages of software development, including scale changes or writing components using a particular programming language, will be slowed down.

Second, high-level web architecture is difficult to amend or modify in the later stages of product development. Typically, major changes of this kind literally mean you have to rebuild the product you want from scratch. Such a decision means postponing the release date, as well as losing financial resources associated with your inability to use components from the previous version of your Node.js, Python, or Java web application architecture.

Third, web app maintenance can become more expensive if you made bad decisions at the overall architecture development stage.

It is, of course, impossible to foresee everything when you create your web application. The technology, market, user needs, and business goals of your company can change very quickly in these turbulent times. However, we will try to arm you with the basic rules of working on a web architecture that will save you time and effort.

Are you about to develop your first IT product? We’ve got a guide for you — (How to Do Market Research for a Startup.)[https://lanars.com/blog/how-to-do-market-research-for-startup]

Реализация MVC в ASP.NET

В инфраструктуре MVC контроллеры — это классы C#, обычно производные от класса System.Web.Mvc.Controller. Каждый открытый метод в классе, производном от Controller, является методом действия который посредством системы маршрутизации ASP.NET ассоциируется с конфигурируемым URL. Когда запрос отправляется по URL, связанному с методом действия, операторы в классе контроллера выполняются, чтобы провести некоторую операцию над моделью предметной области и затем выбрать представление для отображения клиенту.

Взаимодействия между контроллером, моделью и представлением показаны на рисунке ниже:

В инфраструктуре ASP.NET MVC Framework используется механизм визуализации — компонент, отвечающий за обработку представления с целью генерации ответа для браузера. В ранних версиях MVC применялся стандартный механизм визуализации ASP.NET, который обрабатывал ASPX-страницы с использованием модернизированной версии синтаксиса разметки Web Forms. В MVC 3 появился механизм визуализации Razor, усовершенствованный в версии MVC 4 (и оставшийся неизменным в версии MVC 5), в котором применяется совершенно другой синтаксис.

Среда Visual Studio обеспечивает поддержку средства IntelliSense для механизма Razor, упрощая внедрение и ответ на данные представления, передаваемые контроллером.

Инфраструктура ASP.NET MVC не налагает никаких ограничений на реализацию модели предметной области. Модель можно создать с помощью обычных объектов C# и реализовать постоянство с применением любой базы данных, инфраструктуры объектно-реляционного отображения или другого инструмента работы с данными, поддерживаемого .NET.

Data Access Layer

The Data Access Layer contains methods that assist the Business Access Layer in writing business logic, whether the functions are linked to accessing or manipulating data. The Data Access Layer’s major goal is to interface with the database and the Business Access Layer in our project.

The structure will be like this.

In this layer we have the following folders. Add these folders to your Data access layer

• Contacts
• Data
• Migrations
• Models
• Repositories

Contacts

In the Contract Folder, we define the interface that has the following function that performs the desired functionalities with the database like

Migrations

The Migration folder contains information on all the migrations we performed during the construction of this project. The Migration folder contains information on all the migrations we performed during the construction of this project.

Models

Our application models, which contain domain-specific data, and business logic models, which represent the structure of the data as public attributes, business logic, and methods, are stored in the Model folder.

Repositors

In the Repository folder, we add the repositories classes against each model. We write the CRUD function that communicates with the database using the entity framework. We add the repository class that inherits our Interface that is present in our contract folder.

1.1. Разделение между Internet и WWW¶

1.1.1. Что такое Internet?

Internet – глобальная система объединённых компьютерных сетей. Другими словами — сеть сетей.

Инфраструктура, которая позволяет передавать любые типы данных между сетями и устройствами, подключенными к ней.

Частичная карта Интернета

Эта инфраструктура поддерживается сетевыми протоколами – алгоритмами, которые реализуют различные сервисы по передачи данных.

Существует несколько стеков сетевых протоколов, основные: OSI и ICP/IP. Рассмотрим на примере ICP/IP.

Стэк TCP/IP (представлены не все протоколы)

Из этого множества протоколов и уровней, в Web’e нас больше всего интересуют протоколы прикладного уровня (приложений).
В частности: HTTP, FTP, DNS, SSH, P2P. Но для полноты понимания немного затронем и другие уровни.

Примечание

Прикладной уровень:

• HTTP – протокол передачи гипертекстовых документов.
• FTP – протокол передачи файлов.
• DNS – доменная система имён.
• SSH – защищенное подключение к консоли, удалённое управление операционной системой.
• P2P (Peer-to-Peer) – каждый узел является как клиентом, так и выполняет функции сервера.

Транспортный уровень:

• TCP – надежная последовательная передача данных. С подтверждением получения.
• UDP – не надежная передача данных. Без подтверждения получения.

Сетевой уровень:

1.1.2. Что такое WWW?

World Wide Web – распределённая система взаимосвязанных, посредством гиперссылок, документов и их ресурсов, располагающихся на машинах подключенных к Internet. Эта система посредством протоколов серверного и клиентского ПО обеспечивает доступ к этим вазимосвязанным документам.

Примечание

Распределённая – означает, что физически, документы и их ресурсы могут располагаться на разных серверах.

Связанность документов и ресурсов посредством гиперссылок

Примечание

Историческая справка – изначально, WWW разрабатывалась как система ссылок в научном сообществе.

How WebServices Work?

How Web Services Work?

The above diagram shows a very simplistic view of how a web service would actually work. The client would invoke a series of web service calls via requests to a server which would host the actual web service.

These requests are made through what is known as remote procedure calls. Remote Procedure Calls(RPC) are calls made to methods which are hosted by the relevant web service.

Java

The main component of a web service design is the data which is transferred between the client and the server, and that is XML. XML (Extensible markup language) is a counterpart to HTML and easy to understand the intermediate language that is understood by many programming languages.

So when applications talk to each other, they actually talk in XML. This provides a common platform for application developed in various programming languages to talk to each other.

Web services use something known as SOAP (Simple Object Access Protocol) for sending the XML data between applications. The data is sent over normal HTTP. The data which is sent from the web service to the application is called a SOAP message. The SOAP message is nothing but an XML document. Since the document is written in XML, the client application calling the web service can be written in any programming language.

Очередь сообщений

Современная веб-архитектура складывается из отдельных управляемых компонентов — микросервисов. Микросервисы используют для взаимодействия друг с другом RESTful API или очереди сообщений. Очереди сообщений организуют асинхронный канал обмена сообщениями между двумя микросервисами по типу «издатель — подписчик» (pub-sub).

У очередей сообщений есть несколько преимуществ перед асинхронными RESTful-интерфейсами. Например, если во время REST-запроса происходит ошибка, инициатор запроса (клиент) должен суметь её обработать. Кроме того, некорректное REST-сообщение будет просто отклонено и никуда не сохранится. А вот очереди сообщений хранят все сообщения.