Файл: Понятие прикладных протоколов и серверы приложений (ГБУЗ РК КРЦМКИСМП).pdf

Telnet (полное название: Terminal network) – протокол, по словам тех же авторов, «предназначенный для осуществления удаленного доступа к устройствам. Принцип работы аналогичен протоколу SSH с отличием лишь в том, что данные передаются в незашифрованном виде. Задачами протокола Telnet является выполнение скриптов и приложений на удаленных компьютерах, обработка данных, поступающих от устройства, и приведение их к стандартному виду» [8, c.11].

SMTP (Simple Mail Transfer Protocol), по определению Н.В. Тарченко и П.В. Тишкова, является «упрощенным протоколом электронной почты, маршрутизирующим электронные сообщения. Он работает на прикладном уровне и обеспечивает средства обмена сообщениями. SMTP не предусматривает пользовательского интерфейса для приема и передачи сообщений, однако его поддерживают многие приложения электронной почты Интернет. Для передачи почтовых сообщений в сети SMTP используют протоколы TCP и IP» [23, c.29].

SNMP (Simple Network Management Protocol), как пишет А.Н. Сергеев, – это «протокол стека TCP/IP, используемый для управления и наблюдения за сетевыми устройствами [20, c. 87].

RTSP (Real Time Streaming Protocol), отмечает Д. Семенев, «описывает передачу в реальном времени различной потоковой информации, в первую очередь видео и звука. Механизм работы выглядит так: клиент (в нашем случае – ПО видеонаблюдения) отправляет к источнику данных (IPкамера) запрос вида: rtsp://server.name/mpeg4, после этого начинается передача видеопотока. […] Если и камера, и программное обеспечение поддерживают RTSP, то с вероятностью 99% они будут совместимы^[7].

SSL (Secure Sockets Layer), пишет А.Ю. Филимонова, –является «самостоятельным протоколом шифрования, поверх которого может работать как протокол HTTP, так и, например, протоколы FTP и SMPT. Протокол SSL обеспечивает шифрование на уровне протоколов DES (Data Encryption Standard) и MD5 (Message-Digest Algorithm), в то же время он достаточно гибок для использования других методов шифрования» [25, c.445].

NFS (Network File System) – протокол, который, по словам того же автора, «позволяет монтировать в единое целое несколько, возможно удаленных друг от друга, машин и предоставлять доступ к файлам каждой из них.

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

Функционирование NFS-системы базируется на протоколе NFS, который предназначен для предоставления универсального интерфейса работы с файлами для различных типов компьютеров, операционных систем, сетевых архитектур и транспортных протоколов.

Универсальность и переносимость NFS достигается за счет использования двух протоколов:

- RPC (Remote Procedure Call) – протокол удаленных процедур, который служит основой построения удаленной файловой системы.

- XDR (eXternal Data Representation) – протокол универсального представления данных». [23, c. 465]

FTAM (File Transfer Access and Management), как отмечают авторы «Основ компьютерных сетей», – это «протокол передачи и обеспечения доступа и управления файлами» [16, c.72].

SMB (Server Message Block), или SMB/CIFS (Server Message Block / Common Internet File System), пишут авторы «Обзора протоколов…» – это «протокол с клиент-серверной архитектурой, для удалённого доступа к сетевым ресурсам (файлам, принтерам и др.). Common Internet File System – первая версия протокола. Актуальная версия SMB 2.0 реализована Microsoft и используется в Microsoft Windows Network. Клиенты соединяются с сервером, используя протокол NetBIOS через TCP/IP, NetBEUI или IPX/SPX. После установки соединения, клиенты могут посылать SMBкоманды серверу, который даёт им доступ чтения и записи к файлам, и позволяет выполнять весь перечень действий, которые можно выполнять с файловой системой. Однако в случае использования SMB эти действия совершаются через сеть. Протокол используется для получения доступа и мониторинг файлов и папок по технологии Microsoft Windows Network (SBM/CIFS)» [8, c.9].

1.3. Сервер приложений

Перейдем теперь к рассмотрению другого понятия – сервер приложений. Разные авторы дают разное определение понятию «сервер приложений».

Так, по мнению известного IT-менеджера и ученого М.Л. Аншиной, сервером приложений «называется программный продукт, поставляющий среду выполнения для прикладных компонентов, расположенный между клиентом – с одной стороны и данными и прикладными программами – с другой, который может обеспечить интеграцию различных источников данных и прикладных ресурсов и предоставить компонентам необходимые для них сервисы» [1].

Есть и иное определение «сервера приложений». Как пишут Б.Р. Досмухамедов и C.В. Белов, «серверы приложений – это программное обеспечение, предназначенное для создания систем с выделенными сервисами бизнес-логики […], реализованными, как правило, в виде компонентов» [5].

Старший редактор Network Magazine Джонатан Эйнджел даёт такое определение понятия: «…сервер приложений – это программное обеспечение, выполняющееся на среднем уровне между тонкими клиентами на базе Web и внутренними бизнес-приложениями» [28].

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

Помимо этого, серверы приложений могут: связывать несколько систем с разным аппаратным обеспечением и различными ОС; контролировать представление информации с помощью таких стандартов, как HTML, Dynamic HTML (DHTML), Extensible Markup Language (XML) и т. д.; упрощать повторное использование программных компонентов, кем бы они ни разрабатывались - независимым разработчиком или собственными силами. Среди них CORBA, COM/DCOM, Inter-ORB Protocol (IIOP) и Enterprise JavaBeans (EJB); обеспечивать доступ к базам данных через такие интерфейсы, как Java Database Connectivity (JDBC) и ODBC или посредством прямой поддержки CICS, SAP, Lotus Notes и т. д.; повышать производительность за счет таких возможностей, как распределение нагрузки, кластеризация и оперативная замена; поддерживать функции защиты, такие, как Secure Sockets Layer (SSL), идентификация и цифровые сертификаты; объединять все вышеперечисленное в интегрированную среду разработки (Integrated Development Environment, IDE)» [28].

Вернемся к Б.Р. Досмухамедову и C.В. Белову. К своему определению сервера приложений они добавляют следующее: «Обычно серверы приложений выполняются под управлением серверных операционных систем. Компоненты, реализующие бизнес-логику распределенного приложения и выполняющиеся под управлением сервера приложений, обычно представляют собой объекты, реализующие транзакционную логику. Помимо собственно хостинга компонентов многие серверы приложений позволяют реализовать приложения, устойчивые к сбоям, а также поддерживают создание кластеров» [5].

М. Аншина предлагает такую классификацию серверов приложений: «Попробуем разделить Серверы приложений на группы.

1. Интеграционный Сервер Приложений. (Application -integration-centric application server)

Основная задача такого Сервера - интеграция Бизнес-приложений в единую интеллектуальную среду. Такие Серверы особенно актуальны для организации приложений, связанных с задачами типа Supply Chain (Цепочки Поставщиков) и электронной коммерции. К таким серверам относятся реализации крупнейших поставщиков брокеров объектных запросов - компаний Inprise и Iona». [3]

Далее М. Аншина продолжает свою классификацию: «2. Информационный Сервер Приложений (Data-centric application server)

Деятельность такого сервера сконцентрирована на манипулировании данными. В качестве хранилищ могут выступать произвольные приложения, которые, в частности, не обязательно представляют собой реляционные базы данных и, уж тем, более объектные. Такие серверы берут на себя организацию представления распределенных данных, хранящихся в различных источниках, в объектной парадигме. Естественно, Oracle поставляет серверы именно такого типа.

1. Обрабатывающий Сервер Приложений (Processing-centric applica-

tion server)

Центральной заботой таких серверов является обеспечение специфической бизнес-логики. Например, сервер, реализующий распределенные вычисления, или сервер ERP-системы. К таким реализациям относится IBM Websphere».

Третий тип серверов приложений – тот, о котором писали Б.Р. Досмухамедов и C.В. Белов [6], а также П.П. Олейник [14, c.127].

Вернемся к М. Аншиной и её классификации: «4. Управляющий Сервер Приложений (Rules-based application server)

Такие серверы являются подмножеством Обрабатывающих Серверов Приложений, но в отличие от них сконцентрированы на выполнении определенных бизнес-правил. Они ориентированы прежде всего на область электронной коммерции. Примером таких серверов является реализация от компании Vision Software.

5. Сервер XML (XML Server)

Этот сервер представляет собой подмножество Информационного сервера, с той лишь разницей, что в качестве хранилищ данных выступают XML-документы. С другой стороны, такой сервер может представлять собой подмножество Интеграционного сервера, в котором в качестве механизма интеграции выбран XML. Известна реализация такого сервера от компании Bluestone Software»^[8].

В этой классификации серверов приложений, казалось бы, всё четко и подробно расписано по группам. Однако автор далее добавляет следующее: «Не следует думать, что разделение Серверов Приложений по группам такое четкое. Наиболее интересные экземпляры Серверов Приложений гармонично сочетают в себе достоинства различных групп. Кроме того компании-разработчики активно развивают свои продукты. А каждая новая версия, естественно, богаче предыдущей» [1].

Вот так, по мнению В. Дмитриева, выглядит общая схема работы сервера приложений:.

Рис. 2. Общая схема работы сервера приложений [5]

Вернемся к Досмухамедову Б.Р. и Белову С.В. Они пишут: «В настоящее время серверы приложений являются основой многих корпоративных решений, например распределенных приложений […]» [5].

П.П. Олейник отмечает про сервера приложений следующее: «В литературе по проектированию ПО широкое распространение получила плагинная (модульная, plugginable) архитектура. При этом предполагается разработка унифицированной архитектуры загрузки модулей расширений, в которых расположена вся бизнес-логика приложения. Классической реализации присущ существенный недостаток, который требует реализации плагинов в виде отдельных dll-библиотек. В подобной реализации ключевой является проблема модификации существующего программного кода, определяющего бизнес-правила приложения. После внесения изменений необходимо перекомпилировать плагин и загрузить его на СП. Это требует либо физического перезапуска сервера приложений, либо прерывания выполнения клиентских запросов. Поэтому оптимальной представляется такая архитектура, которая позволяет вносить изменения в бизнес-логику приложения без прерывания выполнения запросов, поступающих от клиентских приложений»^[9].

Про трехзвенную модель говорит Барабанова И.А. [3, с. 104], Г. Ладыженский [13] и проч.

Вот, в частности, что пишет Барабанова И.А.: «Трехзвенная модель подразумевает наличие помимо сервера баз данных выделенного сервера приложений, инкапсулирующего в себе основную часть бизнес-логики системы. При этом клиентское ПО осуществляет проведение бизнес-транзакций через сервер приложений уже не в контексте модификации части данных всей базы данных, а строго в рамках бизнес-транзакции. В зависимости от предоставляемой сервером приложений функциональности, бизнес-логику информационной системы может исполнять как со стороны полнофункционального клиентского ПО («толстый» клиент), так и со стороны тонкого клиента, осуществляющего доступ к ресурсам системы через Сеть» [3, с. 104].

Г. Ладыженский замечает следующее: «Основным элементом принятой в AS-модели трехзвенной схемы является сервер приложения. В его рамках реализовано несколько прикладных функций, каждая из которых оформлена как служба (service) и предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться. Серверов приложений может быть несколько, и каждый их них предоставляет определенный набор услуг. Любая программа, которая пользуется ими, рассматривается как клиент приложения (Applicaation Client – AC). Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. AC обращается с запросом к конкретной службе, но не к AS, то есть серверы приложений обезличены и служат лишь своего рода "рамкой" для оформления служб, что позволяет эффективно управлять балансом загрузки. Запросы, поступающие от АС, выстраиваются в очередь к AS-процессу, который извлекает и передает их для обработки службе в соответствии с приоритетами».

Вернемся к И.А. Барановой. По её словам, «трехзвенная модель не ограничивает предприятие в выборе конкретного решения для организации работы сервера приложений. Но по аналогии с серверами баз данных, выступающими в двухзвенной модели и как логическая концепция, и как отдельный программный продукт, в трехзвенной модели наряду с идеологией сервера приложений имеются программные продукты, носящие такое же название. Такие продукты предоставляют стандартные решения проблем, связанных с ограничениями двухзвенной архитектуры, и позволяют при разработке сосредоточить усилия компании исключительно на реализации бизнес-логики, используя для решения остальных вопросов функциональность, предоставляемую самим сервером приложений [3].