15.2. Архитектура Web-приложений, публикующих бд

При публикации БД на Web-страницы в архитектуруWeb-приложений вводятся дополнительные уровни, включающие сервер БД, сервер приложе ний и источник БД.

При такой архитектуре Web-cepeep передает запрос на генерациюWeb- страниц программе-расширениюWcb-еервера, которая формирует требуемый документ по информации из БД и затемWeb-cepnep отсылает готовыеWeb- страницы обратно обозревателю. Для формирования динамических страниц используются различные средства и технологии:ASP и ЮС/НТХ-страни- цы, программы-расширения сервера на основе интерфейсовCGI иISAPI.

При использовании ASP, РНР иIDC/HTX-страниц запрос на получение динамически формируемойWeb-страницы передается специальным динами­ческим библиотекам, входящим в составWeb-cepeepa. Например, если в ка­чествеWeb-сервера используетсяPersonal Web Server и публикация осуще­ствляется средствамиIDC/HTX, то применяется динамическая библиотека«httpodbc.dll». Такие библиотеки анализируют файлASP или ЮС и НТХ- файлы, которые используются в качестве шаблонов.

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

При динамическойпубликацииWeb-страницы создаются после поступле­ния запроса пользователя наWeb-cepeep. Поступивший запрос на генерациюWeb-страницWeb-сервер передает программе-расширению сервера, которая формирует требуемый документ, и затемWfeb-сервер отсылает готовыеWeb- страницы обратно обозревателю.

Программы-расширения Web-cepeepa, публикующие базы данных, ис­пользуют принципы, на которых строятся приложения БД. При статисти­ческой и при динамической публикации должна использоваться архитек­тура приложений БД, дополненная характерными компонентами архитектурыWeb-приложений. Рассмотрим архитектуруWeb- приложе­ний, использующих БД.

Двухуровневые ШеЬ-приложения

При двухуровневой архитектуре Web-приложений источник БД хранится на том же компьютере, где находитсяWeb-сервер. Для доступа к источнику БД используются модули расширения. В простейшем случае в архитектуруWeb-приложений добавляется источник БД (рис. 15.5).

Схема функционирования Web-приложения при такой архитектуре зак­лючается в следующем. Обозреватель для начала работы сWeb-приложени­ем отсылаетURL-адрес главной страницыWeb-приложенияWeb-cepBepy. Последний, обработавURL запроса, высы чает главную страницуWeb-при­ложения обозревателю в форматеHTML. Эта страница несет общую инфор­мацию оWeb-приложении и позволяет выбрать требуемую для пользователя функцию из ряда других, предоставляемых этимWeb-приложением. Далее возможны несколько вариантов работыWeb-приложения.

НТМ|_-<границз

Компьютер попьюзагеля Интернета

Уодуш расширения

URl..

Н^ТТР

ооодоезакадя _%

Шеа-сйозрезаткль

i

TCP/IP

Рис. 15.5. Архитектура Web-приложения, использующего БД

Если пользователю нужна определенная информация из БД, то обозрева­тель по ссылке, находящейся в загруженной HTML-странице, формируетURL запроса к модулю расширения сервера, при этом могут использоваться раз­личные технологии в зависимости от используемогоWeb-сервера наWeb-узле и других особенностей работыWeb-приложения.

Например, если на Web-узле установленWeb-cepeep Microsoft Internet Information Server, то может использоваться технологияASP-страниц,IDC/ НТХ-страниц,CGI илиISAPI-технология, а в случае установки сервераApache может применятьсяCGI-технология.

При необходимости формирования параметризованного URL на уровне обозревателя могут использоваться сценарии наJavaScript для проверки пра­вильности ввода параметров запроса.

После того как пользователь выбрал требуемую ссылку, обозреватель от­сылает URL Web-cepee] j. Для обработки такого запроса сервер вызывает тре­буемый модуль расширения и передает ему параметрыURL. Модуль расши­рения сервера формирует SQL-запрос к БД.

Из модуля расширения сервера доступ к БД может осуществляться различ­ными способами и на основе различных интерфейсов. Например, в случае ис­пользования технологии ASP-страниц применяется несколько уровней интер­фейсов: объектная модельADO, объектный интерфейсOLE DB, интерфейсODBC. Также возможен вариант непосредственного доступа к БД. Например, в случае модуляISAPI, разработанного в средеDelphi, для доступа к БД может использоваться один посредник — драйверBDE (Borland DataBase Engine), входящий в состав программных средств модуля расширения сервера.

Недостатки рассмотренной двухуровневой архитектуры состоят в следующем: • повышенная нагрузка на Web-cepeep, заключающаяся в том, что вся ра­бота по обработкеURL-запросов, извлечению информации из БД и фор­

мированию HTML-страниц выполняетсяWeb-сервером и модулями рас­ширенияWeb-cepeepa;

• низкий уровень безопасности, связанный с невозможностью, например, обеспечить требуемый уровень защиты информации в БД от сбоев во время обращения к базе данных из модуля расширения сервера или кон фиденциальности информации БД от администратора Web-узла.

Для преодоления указанных Недостатков применяются Web-приложения с большим числом уровней. Перейдем к их рассмотрению.

Трехуровневые Web-приложения

При внесении в Web-приложение промежуточного уровня, основанного на технологии клиент-сервер, его архитектура расширяется до трехуровне­вой. При такой архитектуре клиентский уровень занимает обозреватель, на уровне сервера находится сервер БД, на промежуточном уровне находятсяWeb сервер и модули расширения сервера. Модуль расширения сервера выс­тупает преобразователем протоколов между клиент-серверным приложени­ем БД иWeb-сервером (рис. 15.6).

KokMMweooepeep ЬД

TCP/IP

Иг* Lf-thMK

данных

Серэер b;J ж

Компьютер погьзовзталя Интернета

SQi ssnpnc

Модули сагткрениг

иге.

сордора

1 ; I

TCP/IP

Ком1ьгвтер Web-c^pespa

Модули расширения

п|к|Ж<ЕЗуЦаш

UWUwnpot НТМ|.^-|»ии11а

ННЛ-шабгои

Web -врйвр

*|-ти.<т(!8ница

МэЬобоэрвеэтвль

TCP/IP

Рис. 15.6. Архитектура трехуровневого Web-приложения, использующего БД

Введение уровня Web-cepeepa в клиент-серверные приложения БД расширяет возможность их применения как для межнлатформенного при­ложения. Принципы взаимосвязи обозревателя иWeb-cepeepa остаются те же, что и в предыдущей архитектуре. Отличия этой архитектуры за­ключаются в организации взаимодействия модуля расширения сервера и источника данных.

5

Для получения данных модуль расширения Web-сервера формирует и от­сылает SQL-запрос удаленному серверу БД(SQL-серверу). На компьютере,

где установлен удаленный сервер БД, содержится и база данных. SQI -сер­вер обеспечивает выполнение запроса и выдачу модулю расширенияWeb- сервера результатов запроса.

Таким образом, в трехуровневой архитектуре вся обработка SQL-запроса выполняется на удаленном сервере. Достоинства такой архитектуры по срав­нению с предыдущей состоят в следующем:

• уменьшение сетевого трафика — в сети циркулиоует минимальный объем информации;

• увеличение уровня безопасности информации, поскольку обработка за­просов к базе данных выполняется сервером БД, который управляет до­ступом к базе данных, запрещая одновременное изменение одной записи различными пользователями и реализуя механизм транзакций;

• повышение устойчивости Web-приложения к сбоям;

• взаимозаменяемость компонентов архитектуры трехуровневого Web- приложения;

• снижение сложности модулей расширения Web-cepeepa, в которых от­сутствует программный код, связанный с контролем БД и разграниче­нием доступа к ней.

Недостатком рассмотренной архитектуры является увеличение вре­мени обработки запросов, связанное с дополнительным обращением по сети к серверу БД. Для устранения этого недостатка между сервером БД и Web-сервером должны использоватвся высокоскоростные надежные линии связи.

Многоуровневые Web-приложения

Дальнейшее развитие архитектуры Web-приложений и технологии «клиент-сервер» привело к появлению многоуровневой архитектуры, в которой между модулем расширенияWeb-cepeepa и базой данных, кро­ме сервера БД, дополнительно вводится сервер приложений. Сервер при­ложенийявляется промежуточным уровнем, который обеспечивает орга­низацию взаимодействия клиентов («тонких» клиентов) и сервера БД (рис. 15.7).

Напомним, что сервер приложений может использоваться для выполне­ния различных функций, которые в предыдущей архитектуре выполнялись сервером БД или модулем расширения Web-cepeepa.

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

Компыотер-сереэр ВД

СерэерВД

Источник йанкых

TCP/IP

приложений

-А

lA-

Сервер пригсмэкий

Кгульютер пользователя Интернета

SQL-janpoc

Мог и расширения

обмревяеля

Компьютер WefccepEeps

"ТЛОЯулк JX1VS *

сер

HTML- ihfiti

иЯ1

ш

We&c«(««p

HTML

НТЫ1- "cTpShr^T™

*>«Ь-обовр»ютепь

ТСР/'Р

Рис. 15.7. Архитектора многоуровневого Web-приложения

Введение дополнительного уровня Web-cepeepa позволяет публиковать информацию из БД локальных сетей в сети Интернет, получать информа­цию от других интранет-сетей илиWeb-узлов. Кроме того, при частичной или полной реорганизации внутренней архитектуры локальных сетей по­является возможность использовать преимущества сетей интранет, касаю­щиеся упрощения дополнительного подключения новых пользователей и администрирования локальной сети.

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

Основные достоинства многоуровневой архитектуры Web-приложений заключаются в следующем:

• разгрузка Web-cepeepa от выполнения части операций, перенесенных на сервер приложений и уменьшение размера модулей расширения сервера на основе разгрузки их от лишнего кода;

• обеспечение более гибкого межплатформенного управления между Web- сервером и сервером БД;

• упрощение администрирования и настройки параметров сети — при внесении изменений в программное обеспечение или конфигурацию сервера БД не нужно вносить изменения в программное обеспечение Web-cepeepa.

При функционировании Web-приложений с использованием многоуров­невой архитектуры сохраняется возможность параллельной работыWeb-обо­зревателей и клиентских приложений БД (рис. 15.8).

компшгор-шре&р ьД

TCP/IP

Сервер БД

Коыпыагер пользователя интранвга

Клиентское лригчжэние

Компьклср-сегэег приложений

TCP/IP

^ Серчер приложений

Компьютер польээеателя

И(!(рвн«ы

SQL .anpou ^

Чодул I psci . ия

сервера —_|

компьютер Webcepeepa

Модули расширена! , обозревателя

URL

ЫЩэщюе

Wnb-'»pSC!p

HTML

«еочжюэреезиепь

TCP/IP

Рис. 15.8. Архитектура смешанного Web-приложения

В этом случае говорят об архитектуре смешанного Web-приложения. При гакой архитектуреWeb-при пожения и клиентские приложения БД могут па­раллельно получать доступ к источнику БД.

Web-приложения на основе CORBA

Архитектура современных Интернет-приложений - это трехзвенная мо­дель с использованием клиент/серверной архитектуры и интерфейса CGI. Однако использованиеCGI-интерфейса для объектно-ориентированных кли­ентовJava не эффективно, из-за того, что этот интерфейс достаточно медлен­ный и не обладает требуемой гибкостью. Отметим, что попытки некоторых фирм-разработчиков программного обеспечения серверов оживитьCGI, вне­дряя в него серверныеAPI, являются тупиковыми.

Одним из перспективных направлений развития интранет-сетей является ис­пользование технологии CORBA (Common Ob ct Request Broker Arhitectur - общая архитектура брокеров объектных запросов) в сочетании с технологиейJava-anmieTOB. CORBA представляет собой шину (интерфейс) распределен­ных объектов с открытыми стандартами, используемую в клиент/серверных системах. Эта технология явилась результатом работы консорциумаOMG

(Object Management Group — группы управления объектами). Единственной конкурентоспособной технологией, обладающей аналогичными возможнос­тями, является технологияDCOM (Distribute Common Object Model — рас­пределенная модель объектов общего применения), разработанная фирмойMicrosoft.

Технология Java предполагает большую гибкость при разработке распре­деленных приложений, но в полной мере не поддерживает технологию кли ент/сервер. ИнтерфейсCORBA позволяет обеспечить связь переносимых приложенийJava и объектовCORBA. Технология объектовCORBA предназ­начена для использования вWeb-приложениях вместоCGI-интерфейса.

В результате объединения Java-апплетов иCORBA-интерфейса появилось новое понятие — объектная модельWeb, означающая использование объект­ных моделей различных интерфейсов (моделиCORBA, ADO и др.) при по­строенииWeb-приложений. Архитектура такого многоуровневого клиент/ серверногоWeb-приложения, построенного на основе технологииCORBA иJava приведена на рис. 15.9.

Рис. 15.9. Архитектура многоуровневого Wfeb-приложения на основе технологии CORBA

На первом уровне находится клиентское приложение - обозреватель. В обозревателе выполняется клиентский Java-anroieT, из которого может осу­ществляться обращение к объектамCORBA.

На втором уровне находится Web-cepeep, обрабатывающийHTTP-запро­сы иCORBA-вызовы клиентских приложений.

На третьем уровне находится сервер-приложений. В его роли могут выс­тупать серверы ORB (Object Request Broker — посредник запросов объектов) или распределенные объектыCORBA, функционирующие как серверы при­ложений промежуточного звена и выполняющие прикладные функции и на­бор компонентных сервисов (услуг). СерверыORB являются унифицирован­ными фрагментами программы, используемыми в распределенных приложениях в качестве связующего звена между клиентскими приложени­ями и сервером.

Объекты CORBA взаимодействуют с серверами БД последнего уровня, используя, например,SQL в случае реляционных БД. Кроме того, объектыCORBA на сервере могут взаимодействовать и друг с другом. В основе меха­низма взаимодействия между объектамиCORBA лежит протоколIIOP (Internet Inter-ORB Protocol — Интернет-протокол взаимодействияORB). ПротоколIIOP основывается на протоколе TCP/IP с добавленными компо­нентами обмена сообщениями и функционирует как общий опорный прото­кол при организации взаимодействия серверовORB и объектовCORBA. В дополнение к ПОР в технологииCORBA используютсяESIOP-протоколы(Enviroument-Specific Inter-ORB Protocols — зависящие от среды протоколы взаимодействияORB), которые применяются в специализированных сете­вых средах.

Java-клиент может непосредственно взаимодействовать с объектомCORBA, используяJava ORB. При этом серверыCORBA замещают уровеньHTTP-сервера и выступают в качестве программного обеспечения промежу­точного уровня, обеспечивая взаимодействие между объектами(object-to- object). ИнтерфейсCORBA ПОР функционирует в сети Интернет так же, как и протоколHTTP.

Протокол HTTP в этом случае используется для загрузкиWeb-докумен­тов, апплетов и графики,CORBA используется для организации с помощьюJava апплетов клиент/серверных приложений.

Серверный компонент CORBA предоставляет «настраиваемый» интер­фейс, который можно конфигурировать с помощью визуальных средств.CORBA- объект обладает определенными функциональными возможностя­ми, реализует инкапсуляцию свойств и методов и генерируемых объектами событий. Можно создавать целые ансамбли объектов, «стыкуя» выходные события с входными методами. Разработка таких визуальных объектоз под­держивается средствами быстрой разработки приложений —RAD (Rapid Application Development). В частности,CORBA-объекты поддерживаются в системахRAD C++Builder, JBuilder иDelphi.

На последнем четвертом уровне размещается сервер ба? данных или дру­гой источник данных, то есть практически любой источник информации, к которому CORBA может получить доступ. Сюда входят процедурные мони­торы транзакций(TP Monitors), MOM (Message-Oriented Middleware - про­межуточное программное обеспечение, ориентированное на обмен сообще­ниями),ODBMS (ODBMS- объектные СУБД), электронная почта и т. д.

В настоящий момент интерфейсы CORBA/HTTP поддерживается почти всеми серверными платформами, включаяUnix, NT, OS/2,NetWare, MacOS, OS/400.

Рассмотрим механизм функционирования Web-приложения при исполь­зовании технологииJava-anruieToB и объектовCORBA.

Для начала работы с Web-приложением вWeb-обозреватель загружается главнаяHTML-страница, которая содержит встроенные апплетыJava. При этомJava-апплеты и используемые в апплетеJava-классы подгружаются сWeb-cepeepa при открытииHTML-страницы. ПричемWeb-обозреватель формирует запросWeb-cepeepy на поискJava-апплета ил требуемогоJava класса.Web-cepeep находит апплет и загружает его в обозреватель в форме байт-кода.Web-обозреватель при загрузке апплета сначала запускает систе­му безопасности реального времениJava. Для вызова апплетом серверных объектовCORBA используетсяIDL-сгенерированный клиентский стаб(Interface Definition Language - пассивный язык написания интерфейсов), который позволяет вызывать объекты сервераORB или может использоваться интерфейс динамических вызововCORBA DII (Dynamic Invocation Interface) для генерации запроса к серверу при выполнении апплета.

Объединение технологий CORBA, Java и Интернета обеспечивает приво­димые ниже достоинства.

• Масштабируемость и устойчивость Web-приложения, заключающиеся в том, что серверыWeb иORB могут взаимодействовать с использовани­емCORBA ORB. При этом объектыORB могут выполняться на несколь­ких серверах для обеспечения баланса нагрузки(load-balancing) серве­ров для входящих клиентских запросов.ORB может отправить запрос первому доступному объекту, а также увеличить число доступных объек­тов по необходимости.CORBA позволяет объектам сервера действовать последовательно, используя транзакции и связанные сервисыCORBA. В отличие от технологииCORBA, интерфейсCGI при большом количе­стве запросов не имеет возможности распределить нагрузку между не­сколькими процессами или процессорами.

• Гибкость архитектуры CORBA позволяет клиентам непосредственно вызвать методы на сервере. Клиенты передают параметры напрямую, используя прекомпилированные стабы, или генерируют их во время вы­полнения апплета, используя сервисы динамических вызововCORBA DII. Можно вызывать на сервере любой метод, определенный с помощьюIDL, а не только один метод, описанный посредствомHTML, можно пе­редавать любые типизированные параметры вместо обычных строк.

• CORBA расширж т возможностиJava по взаимодействию с распределен­ными объектами. Так какJava-эпплеты не могут взаимодействовать сквозь все адресное пространство, используя вызовы удаленных мето­дов, то дляJava-anmieTOB не существует простого способа вызвать метод на удаленном объекте.CORBA позволяетJava -апплетам взаимодейство­вать с другими объектами, написанными на различных языках, преодо­левая адресное пространство и сети.CORBA обеспечивает богатый на­бор сервисов распределенных объектов (метаданные, транзакции, безопасность, именование, коллекции и т.д.), которые расширяютJava.

• CORBA расширяет объектную модельJava для распределенной среды и позволяетJava-ai iплетам вызывать широкий спектр определенных наIDL операций на сервере. В противоположность этому, клиентыHTTP огра­ничены небольшим набором операций. Приложения серверной части - это обычные объектыCORBA. Следовательно, они доступны в любой момент времени. Нет необходимости проходить через издержки обраще­ния кCGI-сценариям для каждого вызова.

• CORBA предоставляет средства для создания трехзвенной архитектуры клиент/сервер. Кроме того, технологияCORBA разгружает кодJava-an- плетов, определенные компоненты могут быть распределены в среде кли­ент/сервер. Клиентская часть апплета может оставаться маленькой, что сокращает время загрузки апплета.

Кроме технологии CORBA, для расширения возможностей примененияWeb могут использоваться следующие конкурирующие технологии: сокеты,DCOM сActiveX иRMI (Remote Method Invocation — механизм вызова уда ленных методов) цругие технологии. Тем не менее, технологияCORBA оста­ется лидером среди всех интерфейсов распределенных объектов благодаря хорошим архитектурным и функциональным возможностям, устойчивости в работе и легкости в настройке.

В частности, технология CORBA по сравнению с ближайшим ее конку­рентом — технологиейDCOM обеспечивает следующие преимущества:

•полная и корректная реализация поддержки различны* ОС;

• CORBA реализована целиком наJava, в связи с этим она хорошо интег­рируется сJava;

• легкость конфигурирования и настройки серверов и клиентов CORBA;

• корректная реализация вызовов распределенных методов;

• полнота функциональной реализации динамического наследования и поддержки метаданных;

• более высокая (более чем на 20%) производительность приложений;

• корректная реализация механизма транзакций;

• корректная реа-шзация долговременных, или сохраняемых объектных ссылок;

• поддержка CORBA-интерфейсомURL-имен;

• открытый стандарт CORBA-интерфейса.

Таким образом, CORBA обеспечивает инфраструктуру распределенных объек­тов, что позволяет приложениям распространяться через сети, языки, границы компонентов и операционные системы.Java обеспечивает инфраструктуру пе­реносимых объектов, которые работают на всех основных операционных систе­мах.CORBA дает независимость от сетей,a Java — независимость от реализации.

Для организации связи программных расширений Web-cepeepa с БД исполь­зуются современные интерфейсы доступа к даннымOLE DB, ADO иODBC. Эти интерфейсы являются промежуточным уровнем между источником дан­ных и приложением, в качестве которого выступают программные расшире­нияWeb-cepeepa. Рассмотрим особенности архитектурыWeb-приложений, использующих интерфейсы доступа к даннымOLE DB, ADO иODBC.

Характеристика интерфейсов OLE DB, ADO и ODBC

Современные интерфейсы доступа к источникам данным OLE DB, ADO иODBC, внедряемые фирмойMicrosoft, позволяют осуществлять доступ к ис­точникам различных данных однообразным способом. В основе новой техно­логии доступа к данным лежит интерфейсOLE DB, позволяющий связывать и встраивать объекты из любых источников данных. Напомним, что интер­фейсOLE DB является универсальной технологией для доступа к любому источникам данных через стандартный интерфейс СОМ. ИнтерфейсOLE DB основан на механизме сервис-провайдеров (поставщики данных), находящих­ся на высоком уровне абстракции над физическим форматом данных.

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

Архитектура Web-приложений, использующих интерфейсыOLE DB, ADO иODBC, приведена на рис. 15.10.

Интерфейс ADO находится на более высоком уровне абстракции, чем ин­терфейсOLE DB. Он реализован в виде иерархической модели объектов для доступа к различнымOLE DB-провайдерам данных. В модельADO входит набор объектов, которые обеспечивают соединение с провайдером данных, со­зданиеSQL-запроса к данным, создание набора записей на основе запроса и др.

Особенность функционирования Web-приложений, использующих интер­фейсADO, заключаются в том, что обозреватель может извлекать информа­цию из любого источника данных, находящегося в сети Интернет, заранее не имея представления о логической структуре, типе и физическом формате ис­точника данных. То есть появляется возможность публиковать требуемую информацию в Интернете, не показывая внутреннюю структуру данных.

Рис. 15.10. Архитектура Web-приложений, использующих интерфейсы OLE DB, ADO и ODBC

Таким образом, интерфейс ADO позволяет стандартизовать все существу­ющие интерфейсы для доступа к любым данным в интранет/Интернет сетях. Он объединяет все существующие интерфейсы и предоставляет однообраз­ный способ для доступа к любому источнику данных через любой интерфейс.