Анализ механизмов передачи крупных массивов данных через сеть интернет с помощью технологии веб-сервиса

Аннотация

И.А. Натальченко

В настоящее время сеть Интернет прочно вошла в жизнь почти каждого человека, стала неотъемлемой средой поддержки бизнес-процессов. С ростом производительности вычислительной техники увеличился объем обрабатываемой информации, получают все более широкое распространение клиент-серверные технологии, позволяющие производить распределённые вычисления. С учетом всех этих факторов, все большую актуальность приобретают механизмы обмена данными между клиентом и сервером с помощью сети Интернет…
Ключевые слова: клиент-сервер, сетевая архитектура, массив данных, сеть Интернет, механизмы передачи данных, программное обеспечения

05.13.01 - Системный анализ, управление и обработка информации (по отраслям)

Южный федеральный университет, г. Ростов-на-Дону

В настоящее время сеть Интернет прочно вошла в жизнь почти каждого человека, стала неотъемлемой средой поддержки бизнес-процессов. С ростом производительности вычислительной техники увеличился объем обрабатываемой информации, получают все более широкое распространение клиент-серверные технологии, позволяющие производить распределённые вычисления. С учетом всех этих факторов, все большую актуальность приобретают механизмы обмена данными между клиентом и сервером с помощью сети Интернет [1].
Клиент-сервер (англ. Client-server) ― сетевая архитектура, в которой устройства являются либо клиентами, либо серверами. Клиентом (front end) является запрашивающая машина (обычно компьютер пользователя), сервером (back end) ― машина, которая отвечает на запрос. Оба термина (клиент и сервер) могут применяться как к физическим устройствам, так и к программному обеспечению.
Приложения, при подобной архитектуре, делятся на две части: первая, клиентская, инициирует распределенные операции, а вторая, серверная, обеспечивает их выполнение. Такая организация снижает вероятность возникновения узких мест, распределяя рабочую нагрузку между несколькими системами. Также обеспечивается гибкость дизайна приложений, которая была недоступна раньше, в эпоху централизованных сетевых узлов. Но в такой двухзвенной архитектуре имеются и свои ограничения. Для решения проблем связанных с отказоустойчивостью и масштабируемостью была предложена трехзвенная модель, разделяющая приложения на презентационную часть,  промежуточное звено, содержащее бизнес-логику, и третье звено, непосредственно связанное с данными. Такая модель распределения стала наиболее популярным способом разделения приложений. Она позволила сделать прикладные системы масштабируемыми.
Основой для взаимодействия между распределенными частями приложения в ней являются вызовы удаленных процедур (RPC). Чтобы избавить разработчиков от выполнения заданий нижнего уровня, например, от преобразования данных или от их побайтового упорядочивания на различных машинах, на рынок был выпущено программное обеспечение нового уровня. Это промежуточное программное обеспечение скрывает различия между типами сетевых узлов. Оно размещается над операционными системами и сетевыми службами, установленными на этих хостах, обслуживая находящиеся на более высоком уровне приложения.
В настоящее время разработан ряд механизмов, позволяющих клиенту отправлять массивы данных на сервер  через сеть Интернет.
Первые промежуточные программные продукты, например DCE, основывались на модели процедурного программирования. Им на смену пришла объектно-ориентированная модель, реализуемая в промежуточных программных продуктах CORBA, DCOM или RMI, которые являются наиболее популярным программным обеспечением этого класса в настоящее время. Каждая из них имеет свои преимущества и недостатки [1].
Все эти три технологии использования промежуточного программного обеспечения работают по одному схожему сценарию. Их отличия проявляются, прежде всего, в разных поддерживаемых возможностях, а также в уровне сложности. Все они приводят к установлению надежного соединения клиента с сервером, поэтому любое из вышеперечисленного промежуточного программного обеспечения пригодно для использования. Из-за различия в протоколах нельзя осуществить вызов DCOM-сервера из RMI-клиента. (Одним из шагов по решению этой проблемы является обращение к механизму, вызывающему RMI поверх IIOP, который используется при разработке с применением Enterprise JavaBeans). При этом устанавливается соединение по принципу "от точки к точке". Следует также отметить, что данное промежуточное программное обеспечение обычно используется для интранет-приложений и организовать его работу через брандмауэр весьма проблематично. Для подключения к серверу за брандмауэром все эти технологии предусматривают механизм HTTP- туннелирования. Данные проблемы были решены в технологии веб-сервисов (web-service).
Промежуточное программное обеспечение, которое упоминалось ранее, используется в качестве двоичного протокола связи. Веб-сервисы используют XML поверх протокола HTTP, поэтому не возникает никаких проблем при работе через брандмауэры, поскольку они обычно не блокируют порт HTTP. Веб-сервисы, кроме этого, в качестве альтернативы, могут использовать протоколы FTP и SMTP.
XML является главным элементом практически всех уровней, используемых при создании веб-сервисов.
Веб-сервис состоит из нескольких уровней [2,3]:

• Язык расширяемой разметки (XML).
• Протокол доступа к простым объектам SOAP (Simple Object Access Protocol). Определяет взаимодействие между инициатором запроса и поставщиком. Данный протокол независим от среды выполнения. Задает простейший механизм выражения семантики приложения, обеспечивая создание модели модульной компоновки и механизмов кодирования, для преобразования данных внутри модулей. Протокол не определяет ни семантику приложения (модель программирования), ни семантику, зависящую от реализации (механизм регенерации освобождаемой памяти).
• Язык определения веб-сервисов WSDL (Web Service Definition Protocol). Описывает сервисы, предлагаемые поставщиком, которые могут использоваться как средство создания правильных сообщений SOAP для доступа к сервисам. Описывает сетевые сервисы с помощью грамматики XML. Обеспечивается документация для распределённых систем. Ее цель — дать приложениям возможность взаимодействовать друг с другом в автоматическом режиме.
• Универсальная интеграция поиска описаний UDDI (Universal Discovery Description Integration). Стандарт, разработанный для создания пригодного к поиску каталога предприятий и предоставляемых ими веб-сервисов. Таким образом, он является чем-то вроде сервисного агента, который помогает инициаторам сервисных запросов находить подходящих поставщиков сервисов.

Указанные уровни являются основными и позволяют разрабатывать веб-сервисы, которые в соответствии с их формальным определением состоят из трех компонентов.
Технология веб-сервисов, несмотря на свои очевидные преимущества,  имеет ряд недостатков:

• Веб-сервисы находятся в общем доступе и воспользоваться им может любой пользователь сети Интернет. Данная проблема решается с помощью передачи регистрационных данных пользователя в зашифрованом виде. Если конфиденциальность является критическим фактором, то может быть добавлена цифровая подпись.
• Использование XML в качестве формата данных приводит к тому что сообщения имеют очень большой размер (XML-теги занимают много места). Это накладывает определённую нагрузку по созданию, передаче и интерпретации сообщений. При большом объеме сообщения может быть превышено время ожидания и сообщение будет утеряно. Данный фактор также зависит от качества связи.
• В настоящее время сложно представить приложение, которое не использует хотя бы самую простую базу данных, и веб-сервис не является исключением. Однако использование баз данных накладывает свои ограничения. При превышении максимального количества запросов в очереди запросов базы данных вновь приходящие запросы теряются. Кроме этого, если сервер базы данных сильно загружен, и на выполнение приходит сложный запрос, то сервер может не успеть выполнить его за отведённое время.

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

 Литература.

1.Кагаловский М.Р. Перспективные технологии информационных систем. – М.: ДМК Пресс; М.: Компания АйТи, 2003. – 288 с. (Серия «ИТ-экономика»).
2. Нейгел К., Ивьен Б., Глинн Д., Уотсон К., Скиннер М., Джонс А.  С# 2005 для профессионалов. – М.: Изд. Диалектика, 2007. – 1552 с.
3. Троелсон Э. С# и платформа .NET. - М.: Изд. Питер, 2007. – 795с.