Главная Пресс-центр Статьи и публикации Веб-базированный доступ к технологической информации

Веб-базированный доступ к технологической информации

А. Тимербаев, Р. Лангманн

В данной статье рассматриваются три технологии программирования для реализации веб-базированного доступа к технологической информации: IIS-приложения, Remote Scripting и применение Java. Первая часть посвящена IIS-приложениям, одной из серверных технологий веб-программирования фирмы Microsoft, легко применимой для эффективного доступа к технологическим данным. Обсуждаются преимущества и недостатки этой технологии, рассматривается пример программного приложения, а также особенности практического использования таких приложений. Во второй части обсуждается технология веб-программирования Remote Scripting или удаленное исполнение сценариев. Эта технология фирмы Microsoft, малоизвестная даже среди специалистов, позволяет создавать стабильные, надежные и прежде всего прозрачные решения для прикладного доступа к технологическим данным через Интернет/интранет. В качестве примера применения Remote Scripting рассматривается виртуальный лабораторный практикум, в котором изучаются основы технологии INTERBUS. Третья часть посвящена применению языка Java для реализации веб-базированного доступа к технологическому оборудованию. Сетевые возможности Java позволяют создавать гибкие и быстродействующие программные решения для удаленного обслуживания и диагностики. В отличие от двух предыдущих решений, Java позволяет осуществить динамическое представление технологической информации на веб-странице, причем несколькими способами. Приводятся особенности каждого из способов, а также результаты собственного опыта разработки.

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

 

Часть 1: IIS-приложения

  Часть 1 посвящена программной технологии, в которой веб-приложение выполняется на сервере, динамически генерируя веб-страницы в ответ на запросы клиентов, и использует для обмена данными стандартный веб-протокол HTTP. В отличие от других серверных технологий программирования, использующих сценарии (CGI, PHP и т.п.), это решение является прикладным расширением веб-сервера Internet Information Server (IIS) фирмы Microsoft и называется IIS- или WebClass-приложением. По сравнению с веб-базированными решениями, создаваемыми на языках сценариев, IIS-приложения обеспечивают более быстрый и эффективный доступ к технологическим данным.

 
  Принцип работы IIS-приложения  
  Приложения IIS появились как новый тип проекта в среде разработки Microsoft Visual Basic (VB) 6.0. Приложение IIS представляет собой комбинацию текстовой разметки HTML и ActiveX DLL-библиотеки, которая выполняется сервером IIS (рис. 2).

 
 
 
  Приложения IIS состоят в родстве с приложениями ASP (ASP Active Server Pages): к услугам разработчика IIS-приложений предоставляются все объекты ASP с их функциональными возможностями. Однако в отличие от ASP-страниц, IIS-приложения создаются в среде разработки VB и выполняются сервером быстрее, поскольку на исполнение компилированного кода ActiveX DLL-библиотеки IIS-приложения затрачивается меньше вычислительных ресурсов процессора, чем на интерпретацию сценария [1].

 
  На объектном уровне IIS-приложение состоит из одного или нескольких объектов типа WebClass, каждый из которых содержит ряд элементов WebItem. Эти объектные классы описаны в динамической библиотеке Microsoft WebClass Library (mswcrun.dll), которая является также модулем времени выполнения IIS-приложений. Объект WebClass является основной функциональной единицей приложения. Он обрабатывает запросы, приходящие от веб-браузера и формирует полностью или частично исходный код HTML-страницы для ответной отправки пользователю. Реакция объекта WebClass на запросы клиента описывается разработчиком в специальных процедурах. Элементы WebItems могут быть двух типов: HTML Template и Custom WebItem. Первый тип это HTML-шаблоны, содержащие специальные дескрипторы (теги), которые обозначают места динамической вставки актуального содержания, формируемого IIS-приложением. Ко второму типу относятся программные блоки обработки запросов, которые используются для динамического формирования полного HTML-кода веб-страниц, высылаемых объектом WebClass браузеру в качестве ответа на его запрос [2].

 
  Доступ веб-клиента к IIS-приложению начинается с вызова ASP-страницы, которая автоматически создается средой разработки VB при компиляции IIS-проекта. Этот ASP-файл является, по сути, интерфейсом между веб-клиентом и IIS-приложением. Веб-сервер IIS загружает библиотеку ActiveX DLL данного IIS-приложения в свое адресное пространство и затем исполняет в зависимости от запроса веб-клиента компилированный VB-код. Формируемая при этом HTML-страница отправляется клиенту в качестве результата запроса.

 
  Чтобы предоставить веб-клиенту актуальную информацию о технологическом процессе автоматизированной установки, IIS-приложение должно осуществить доступ к интерфейсу технологических данных, считать необходимые данные реального времени и отправить их клиенту вместе с остальным содержанием HTML-страницы. Доступ к переменным процесса на технологическом сервере с целью чтения или изменения их значений может быть реализован либо через специфичный для данного оборудования автоматизации драйвер, либо через имеющийся в распоряжении OPC-сервер (OPC OLE for Process Control).

 
  Для обмена оперативными данными на основе стандарта ОРС приложение IIS может использовать интерфейс ОРС Automation Interface, специально предназначенный для VB-приложений [3].

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

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

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

 
  Однако IIS-приложения, формирующие в ответ на запрос пользователя статические веб-страницы, не позволяют осуществить динамического обновления значит, и представления) данных на стороне веб-клиента. Кроме того, они могут быть использованы только совместно с веб-сервером IIS фирмы Microsoft.

 
  Еще один недостаток заключается в «непрозрачности» IIS-приложений. Приложение ActiveX DLL представляет собой закрытый объект, недоступный для дальнейшей обработки и использующий HTML-шаблоны или программно генерируемые HTML-страницы, определенные программистом на этапе разработки. Хотя HTML-файлы шаблонов и являются отличной возможностью для пользователя, владеющего HTML, создать собственный дизайн для динамически генерируемых веб-страниц, на основе одного шаблона может создаваться только одна веб-страница, причем количество динамических вставок также заранее определено программистом.

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

 
  Пример приложения: WebOPCClient  
  Программное обеспечение WebOPCClient представляет собой несложное IIS-приложение и служит для отображения актуальных технологических данных на веб-странице в виде таблицы (рис. 1). В качестве интерфейса доступа к данным технологического процесса используется ОРС. Доступ к технологической информации с помощью WebOPCClient в целях мониторинга или управления защищен соответствующими паролями.

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

 
  Имя OPC-сервера, с помощью которого осуществляется доступ к технологической информации, а также список идентификаторов ОРС-переменных, необходимых для мониторинга и управления процессом, предварительно задается в файле инициализации с расширением INI, который находится в каталоге IIS-приложения. В INI-файле могут быть также заданы и другие настройки приложения: символические имена, под которыми ОРС-переменные должны фигурировать в таблице на веб-странице, пароли для доступа к данным в режиме чтения и записи значений переменных, необходимость отображения отдельных столбцов таблицы и т.п.

 
  Таблица с технологической информацией, также как и некоторые другие элементы веб-страницы, создается IIS-приложением динамически. Динамическая вставка отдельных фрагментов HTML-страницы происходит в местах расположения определенных тегов в файле-шаблоне, на базе которого строится отправляемая клиенту страница. По умолчанию это тег WC@, хотя по желанию разработчика он может быть переопределен. Например, веб-страница, представленная на рис. 1, создается на основе HTML-шаблона Tmpl1, в котором вместо тела таблицы присутствует только тег WC@ с текстом Table_Body (см. фрагмент 1 на рис.3).

 
 
 
  При нажатии на веб-странице кнопки обновления или записи значений технологических переменных сервер IIS получает запрос на посылку клиенту обновленной HTML-страницы, сформированной на базе того же шаблона. В файле-шаблоне IIS производит поиск тегов WC@ и вызывает для каждого найденного тега специальную процедуру ProcessTag. Шаблону Tmpl1 соответствует процедура Tmpl1_ProcessTag (см. фрагмент VB-кода 2 на рис.4). В этой процедуре сервер IIS динамически создает новое HTML-содержание для данного тега WC@ и сохраняет его в строковой переменной приведенном примере в переменной html).

 
 
 
  Доступ к необходимой технологической информации WebOPCClient осуществляет через OPC-сервер, соответствующий используемому оборудованию автоматизации. После установления связи с OPC-сервером веб-приложение создает группу переменных, содержащую необходимые элементы данных OPC, и выполняет в зависимости от запроса клиента чтение или запись значений переменных процесса. Благодаря поддержке распределенной компонентной модели объектов DCOM (Distributed Component Object Model), предусмотренной в OPC, веб-сервер с приложением WebOPCClient и OPC-сервер могут находиться как на одном, так и на разных компьютерах, находящихся в локальной вычислительной сети. Таким образом, функции веб-сервера может выполнять как технологический сервер, так и специально выделенный для этого компьютер.

 
  Результаты доступа к технологическим переменным оформляются IIS-приложением WebOPCClient в виде HTML-таблицы и затем отправляются клиенту в составе обновленной веб-страницы. Демонстрационная версия приложения WebOPCClient доступна для загрузки по адресу: http://www.mitec-buero.de.

 
  Опыт практического использования  
  Приложения IIS особенно предпочтительны для VB-разработчиков, поскольку создавать веб-приложения они могут в привычной для них среде разработки Visual Basic.

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

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

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

 

Часть 2: Remote Scripting

  В методе прикладных расширений веб-сервера (IIS-приложений), описанном в части 1, при каждом требовании клиента выполнить чтение или запись значений технологических переменных происходит новая загрузка актуализированной HTML-страницы. Чтобы избежать повторной загрузки, нежелательной хотя бы по той причине, что на загрузку графических файлов иногда тратится слишком много времени, необходим механизм, который по требованию клиента целенаправленно изменял бы только некоторые элементы HTML-страницы. Таким механизмом является Remote Scripting (RS) фирмы Microsoft.

 
  Принцип работы Remote Scripting  
  Механизм Remote Scripting базируется на технологии ASP (Active Server Pages) и использует как клиентские, так и серверные сценарии.

 
  С помощью Remote Scripting на стороне клиента могут удаленно вызываться функции, реализованные в сценарии ASP-страницы, хранящейся на веб-сервере. Значения, возвращаемые этими функциями, могут быть получены и использованы в клиентском сценарии на языке JavaScript (или JScript по версии Microsoft) без перезагрузки веб-страницы. Механизм Remote Scripting использует для этого три компонента, представленные тремя различными файлами:

 
 
  • RSPROXY.class;
 
 
  • RS.htm;
 
 
  • RS.asp.
 
  Основным компонентом технологии Remote Scripting является Java-апплет RSPROXY.class, обеспечивающий взаимодействие клиентского и серверного сценариев. Ни пользователь, ни программист с этим апплетом непосредственно не работают. Вместо этого для инициализации RS, исполнения удаленных методов, проверки состояния вызова и получения возвращаемых значений в клиентских сценариях используются функции, реализованные на языке JavaScript в файле RS.htm, которые и осуществляют доступ к соответствующим методам апплета.

 
  Таким образом, HTML-страница, в которой должен быть осуществлен удаленный вызов сценариев, должна включать файл RS.htm, а также вызов функции RSEnableRemoteScripting, назначением которой является загрузка и инициализация апплета RSPROXY (см. фрагмент 1 клиентского сценария на рис.7).

 
 
 
  На рис.6 показаны потоки информации при обмене данными между клиентом и сервером при использовании Remote Scripting.

 
 
 
  Через сценарий в RS.htm происходит обращение к методам апплета RSPROXY, который обеспечивает доступ к функциям пользовательского сценария ASP-файла, находящегося на сервере. С помощью директивы INCLUDE к этому файлу подключается серверный компонент технологии Remote Scripting, файл RS.asp (см. фрагмент 1 серверного сценария на рис.8). Позднее он будет использован для вызова необходимых функций серверного сценария. Вызов метода RSDispatch необходим для поиска в сценарии нужной клиенту функции или процедуры.

 
  Далее в пользовательском ASP-файле необходимо реализовать функции и процедуры, предназначенные для удаленного вызова, а также объявить их общедоступными, чтобы механизм Remote Scripting мог их использовать в качестве серверных методов (см. фрагмент 2 серверного сценария на рис.9).

 
 
 
  Удаленный вызов функций и процедур, реализованных на веб-сервере, теперь может быть осуществлен в прикладном клиентском сценарии на языке JavaScript (см. фрагмент 2 клиентского сценария на рис. 10). После выполнения нужной пользователю функции серверная часть веб-приложения отправляет результаты обратно апплету, находящемуся у клиента. При этом клиентский сценарий работает с возвращаемыми значениями, полученными от сервера, так же, как с результатами локальных вызовов функций. Таким образом, Remote Scripting обеспечивает прозрачность доступа к серверным методам.

 
 
 
  Для удаленного вызова серверных методов используется функция RSExecute, также относящаяся к механизму Remote Scripting. В качестве параметров она ожидает относительный унифицированный указатель ресурса (URL Uniform Resource Locator) ASP-файла, содержащего пользовательский серверный сценарий, а также имя и параметры удаленно вызываемой функции или процедуры. В приведенном примере с помощью RSExecute вызывается функция myFunction, не имеющая параметров и реализованная в файле remote.asp, который находится в той же директории сервера, что и файл RS.asp.

 
  Вызов функции myFunction возвращает вместо «нормального» результата выполнения функции объект, инкапсулирующий результаты вызова (со в приведенном примере). В свойствах этого объекта содержится возвращаемое функцией значение (свойство return_value), а также информация о состоянии выполнения удаленного метода. Обработка значения, полученного с сервера, происходит в функции клиентского сценария myCallback.

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

 
 
 
  При асинхронном вызове функции myFunction с приведенными в примере параметрами, вызов функции обработки возвращаемого значения myCallback будет инициирован механизмом Remote Scripting непосредственно после получения сообщения о завершении выполнения функции на сервере.

 
  Технология Remote Scripting позволяет осуществить и передачу параметров для удаленно вызываемых методов, как это, например, необходимо в случае присвоения технологическим переменным новых значений. Более подробную информацию об этом, а также о технологии Remote Scripting вообще можно найти в источниках [4, 5].

 
  Механизм Remote Scripting применим совместно с веб-сервером IIS 4.0 фирмы Microsoft (IIS Internet Information Server) и его более поздними версиями, а также со стандартными браузерами, такими как Internet Explorer или Netscape версии 4.х и выше. Актуальная версия программных компонентов Remote Scripting может быть загружена с веб-сайта компании Microsoft [6].

 
  Преимущества и недостатки  
  Основными преимуществами Remote Scripting для разработчика являются прозрачность, простота и гибкость решений для веб-базированного доступа к технологической информации. Для написания таких веб-приложений не нужны комплексные среды разработки, требующие больших ресурсов и сложные для освоения. Необходимые сценарии в HTML- и ASP-страницах могут создаваться и дорабатываться с помощью любого текстового редактора.

 
  Особенные преимущества проявляются при использовании Remote Scripting в веб-приложениях, которые осуществляют доступ к технологическим данным, предоставляемым OPC-сервером. Для реализации связи и обмена данными при таком доступе в серверном сценарии необходимы лишь несколько строчек кода на языке VBScript.

 
  К дальнейшим преимуществам также относятся:

 
 
  • стабильность и надежность;
 
 
  • простота установки (на веб-сервере необходимо лишь разместить каталог _ScriptLibrary);
 
 
  • использование JavaScript или VBScript на выбор.
 
  Хотя Remote Scripting и осуществляет динамическое встраивание данных в веб-страницу, находящуюся у клиента, для этого так же, как и в IIS-приложениях, необходим предварительный запрос клиента. Механизм Remote Scripting не позволяет событийно-управляемо оповещать клиента о случайном изменении значений технологических переменных на сервере.

 
  К недостаткам технологии относится также и то, что на этапе создания веб-приложений на ее основе разработчик имеет весьма скудные возможности отладки взаимодействия клиентского и серверного сценариев. Кроме того, использование в Remote Scripting технологии ASP-страниц фирмы Microsoft делает этот механизм применимым только совместно с веб-сервером этой же фирмы (IIS).

 
  Пример применения: виртуальный практикум на базе INTERBUS  
  С февраля 2001 года в высшей технической школе города Дюссельдорфа действует виртуальный лабораторный практикум для изучения основ технологии INTERBUS, в котором используется реальная учебная установка (Telepraktikum mit INTERBUS). Веб-базированный доступ к технологической информации установки реализован с помощью механизма Remote Scripting.

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

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

 
  В качестве сервера в практикуме использована двухпроцессорная система с платформой Windows NT 4.0. Управляющая программа установки также исполняется на этом компьютере (рис.12).

 
 
 
  Веб-базированный доступ к технологической информации установки осуществляется с помощью Remote Scripting и OPC-сервера для полевой шины INTERBUS. Каждой HTML-странице веб-сайта практикума (см. рис. 5), с которой осуществляется доступ к технологическим данным с целью чтения или записи значений переменных процесса, на сервере соответствует свой ASP-файл со сценарием, реализующим необходимые операции.

 
 
 
  Таким образом, в веб-браузере клиента реализуются следующие пользовательские функции:

 
 
  • управление установкой с помощью соответствующих кнопок пользовательского интерфейса;
 
 
  • отображение входных и выходных сигналов с помощью графически изображенных светодиодов;
 
 
  • визуализация установки с помощью трехмерной графической VRML-модели установки (VRML Virtual Reality Modeling Language).
 
  Доступ к установке может быть осуществлен в любое время суток по адресу http://www.telepraktikum.de. Выполнению практикума предшествует регистрация пользователя.

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

 
 
  • Механизм Remote Scripting работает надежно и стабильно даже при низких скоростях передачи данных в сети Интернет;
 
 
  • Используемый в практикуме сервер должен обладать достаточной вычислительной мощностью, поскольку ASP и Remote Scripting относятся к относительно ресурсоемким технологиям построения веб-приложений;
 
 
  • При выходе в Интернет со скоростью передачи данных порядка 10 Кбит/с обновление технологических данных на веб-странице, находящейся на стороне клиента, после отправки соответствующего запроса осуществляется за 1-2 с;
 
 
  • В случае Remote Scripting отпадают часто возникающие при использовании веб-приложений проблемы, связанные с определенными ограничениями использования Интернета в корпоративных сетях из соображений безопасности (например, разрешены для обмена только TCP-порты со стандартными номерами, запрещено использование ActiveX-объектов и т.п.). Для работы с веб-приложением, использующим RS, необходим лишь стандартный браузер с поддержкой Java и JavaScript. При этом обмен данными осуществляется на сервере через стандартный TCP-порт 80, соответствующий протоколу HTTP.
 
  В общем и целом, механизм Remote Scripting является хорошим средством для быстрой и гибкой реализации веб-базированного доступа к технологической информации, динамического с точки зрения обработки запросов клиента, но все же не позволяющего осуществить событийно-управляемое оповещение клиента.

 

Часть 3: Применение Java

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

 
  Создание веб-приложения на языке Java  
  Существует несколько технологий создания веб-базированных приложений на языке Java. К основным технологиям относятся Java-апплеты, сервлеты (Servlets) и серверные страницы на языке Java (JSP Java Server Pages).

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

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

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

 
  Альтернативой программному интерфейсу сокетов в языке Java является технология удаленного вызова методов RMI (Remote Method Invocation). Этот механизм предлагается разработчикам, начиная с JDK 1.1 (JDK Java Development Kit), позволяя делать методы локальных программных объектов доступными для удаленных приложений.

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

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

 
  Непосредственный доступ к переменным процесса на технологическом сервере может быть осуществлен либо через программный интерфейс коммуникационного драйвера, специфичного для конкретного оборудования автоматизации, либо посредством соединения с OPC-сервером. Подобные программные модули, как правило, обладают программным интерфейсом для приложений на языке С. Чтобы иметь возможность использовать такой программный интерфейс в приложении на языке Java, можно пойти одним из двух путей:

 
 
  • Сделать программный модуль на языке С, осуществляющий работу с этим интерфейсом, доступным в сети как CORBA-объект;
 
 
  • Работать с интерфейсом, поддерживающим С, непосредственно, используя Java Native Interface (JNI).
 
  Общая архитектура брокера объектных запросов CORBA (Common Object Request Broker Architecture) позволяет осуществить связь между объектами, даже созданными на различных языках программирования. Решение с использованием CORBA является универсальным, но в то же время и достаточно сложным.

 
  В распределенном приложении, полностью написанном на языке Java, использование CORBA не приносит никаких дополнительных выгод, поэтому чаще предпочтение отдается технологии JNI. В этом случае реализация необходимых Java-приложению методов для работы с программным интерфейсом, поддерживающим язык С, осуществляется на языке C или C++ [3]. Таким способом может быть также реализован доступ к технологическим данным через OPC-интерфейс.

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

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

 
 
  • Java является сравнительно простым языком программирования. Быстрому созданию надежного программного кода способствует автоматическое управление памятью, отсутствие многократного наследования и указателей.
 
 
  • Байтовый код Java в большой степени независим от операционной системы или процессора. Благодаря этому приложения на языке Java легко портируются на другие платформы.
 
 
  • С помощью технологий JNI и CORBA может быть реализована связь с объектами, созданными на других языках программирования.
 
  В сравнении с другими программными решениями (например, с Remote Scripting) веб-базированное приложение на языке Java, использующее для обмена данными сокеты, позволяет достичь меньшего времени реакции при оповещении клиента. Недостатком этого способа обмена является, однако, использование TCP-порта с нестандартным номером, который при доступе веб-клиента, находящегося за пределами защищенной сети, к данным технологического сервера, лежащего в ее пределах, должен быть сначала разрешен системным администратором для обмена.

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

 
  Пример приложения: Web Access Kit for Process Data  
  На базе обобщенной схемы распределенного приложения, представленной на рис. 14, было разработано программное обеспечение Web Access Kit (WAK) V1.0, предназначенное для веб-базированного мониторинга и управления. ПО WAK состоит в общей сложности из четырех гибко применяемых Java-апплетов (WAK-апплетов) и серверной части приложения, WAK-сервера. Апплеты служат для чтения и записи значений цифровых и аналоговых технологических переменных. На рис. 15 изображен графический интерфейс апплета для чтения и отображения значений аналоговых технологических переменных.

 
 
Рис. 14. Доступ к данным процесса технологической установки с помощью веб-базированного распределенного приложения на языке Java
 
  Обмен данными между WAK-сервером и каждым из апплетов реализован на основе TCP-соединения с помощью программного интерфейса сокетов. Доступ к данным процесса технологической установки WAK-сервер осуществляет через ОРС-интерфейс.

 
 
 
  Апплеты WAK могут быть гибко и просто встроены пользователем в собственные веб-страницы с помощью обыкновенного HTML-редактора. На одной веб-странице может располагаться сразу несколько WAK-апплетов.

 
  Пример на рис. 13 показывает использование WAK в экспериментальном приложении «Веб-программируемое устройство управления WPS» (WPS Web-programmierbare Steuerung). Модули ввода/вывода учебной сверлильной установки с поворотным столом соединены сетью Ethernet с сервером технологических данных. Таким образом, технологический сервер имеет прямой доступ к сигналам сверлильной установки, который и использует серверная часть приложения WAK. Управление установкой осуществляется на стороне веб-клиента посредством управляющей программы, которая составляется пользователем на веб-странице с помощью языка функциональных блоков (FBD Functional Block Diagram) и выполняется в среде браузера.

 
 
 
  Распределенное приложение Web Access Kit разрешает одновременный доступ к технологической информации сразу нескольких веб-клиентов, число которых программно не ограничено. Таким образом, осуществлять мониторинг и управление технологическим процессом одновременно может сразу несколько операторских станций.

 
  Список технологических переменных, подлежащих мониторингу и управлению, а также настройки визуального представления данных на веб-странице цвета, тип и размер шрифта задаются в списке параметров каждого из апплетов. Список параметров апплета, изображенного на рис. 15, представлен во фрагменте HTML-кода 1 (рис.16).

 
 
 
  Апплеты WAK могут быть использованы также в качестве агентов-посредников proxy, предоставляющих другим программным объектам веб-страницы интерфейс к технологической информации удаленного устройства автоматизации. В этом случае обработка технологических данных, получаемых через прикладной программный интерфейс (API Application Programming Interface) прокси-апплета, может быть осуществлена с помощью сценариев на языках, соответствующих стандарту ECMAScript (JavaScript, JScript и т.п.).

 
  Программный интерфейс апплетов WAK содержит методы для чтения или записи значений технологических переменных. Апплеты, предназначенные для чтения значений цифровых и аналоговых переменных, содержат, например общедоступный метод readItem () (см. фрагмент кода 2 на рис. 17).

 
 
 
  В этом примере в функции read () JavaScript-сценария происходит считывание актуального значения переменной процесса, представляемой апплетом с именем ARead_01 и имеющей порядковый номер index в рамках этого апплета. Считанное значение отображается в текстовом поле HTML-формы, расположенной на данной веб-странице.

 
  Доступ серверной части Java-базированного распределенного приложения WAK к данным OPC-интерфейса осуществляется с помощью специальной библиотеки J2OPC (Java to OPC), которая является связующим звеном между Java-приложениями и OPC. Использование библиотеки J2OPC, созданной на основе технологии JNI, в приложениях на языке Java позволяет программисту работать с OPC-интерфейсом с таким же удобством, как и в проектах на Visual Basic.

 
  В отличие от известных комплексных программных продуктов для веб-базированного удаленного доступа к технологической информации распределенное приложение WAK позволяет создавать гибкие, компактные и недорогие программные решения. Демонстрационная версия приложения Web Access Kit доступна для загрузки по адресу: http://www.telefabrik.de.

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

 
 
  • Распределенные приложения на языке Java, осуществляющие динамический обмен данными, могут эффективно применяться в некритичных по времени задачах автоматизации уже при скорости передачи данных в сети Интернет порядка 10 Кбит/с.
 
 
  • Сервер, выполняющий приложение на языке Java, должен обладать достаточной вычислительной мощностью.
 
 
  • В пробном применении WAK для управления учебной сверлильной установкой с поворотным столом через Интернет, проиллюстрированном на рис. 13, была достигнута частота обновления технологических данных в экранной форме на стороне веб-клиента порядка 100 мс.
 
 
  • Обмен данными в распределенном приложении, построенном на использовании программного интерфейса сокетов, осуществляется через TCP-порт с нестандартным номером, назначаемым пользователем. При доступе к данным защищенной сети извне этот номер порта должен быть разрешен для обмена на соответствующем сетевом экране.
 
  Веб-базированный доступ к технологической информации с помощью Java является, несомненно, одним из наиболее эффективных решений. Java-базированные распределенные приложения для мониторинга и управления обладают малым временем реакции, позволяют реализовать динамическое отображение технологической информации на экране операторской станции и являются платформенно-независимыми. С помощью подобных решений в пределах корпоративной сети интранет или через Интернет может быть осуществлен удаленный анализ критичных по времени данных или удаленное управление установками и оборудованием, при котором должно быть обеспечено заданное, сравнительно малое время реакции.

 

Заключение

  Все три решения находятся сегодня в практическом применении. Решение, использующее технологию Remote Scripting (часть 2), можно протестировать через Интернет. Решения, описанные в частях 2 и 3, могут быть получены в виде демонстрационных или полных версий для ознакомления или использования.

 

Литература

  1. Kofler, M. Visual Basic 6. Programmiertechniken, Datenbanken, Internet. Bonn: Addison-Wesley-Longman Verlag, 1998.

 
  2. Колесов А., Павлова О. Visual Basic 6.0 упрощает разработку для Web. Часть 2: Создание IIS (WebClass)-приложений// КомпьютерПресс. 1999. 5. С.108-112.

 
  www.microsoft.com/rus/msdn/activ/article/library/kolesov/cp9905-2/vb-web2.htm

 
  3. OPC Data Access Automation Interface Specification, Version 2.02. Instead of version 2.01; released 03.02.99. OPC Foundation, 1999. 

 
  4. Койнов Е. Remote Scripting удаленное исполнение скрипта. Сервер Центра Информационных Технологий Citforum.ru, 1998.

 
  www.citforum.ru/internet/common/r_scripting.shtm

 
  5. Using Remote Scripting. Documentation about Microsoft Remote Scripting. MSDN Library. Microsoft Corp.

 
  msdn.microsoft.com/library/en-us/rmscpt/Html/rmscpt.asp

 
  6. Download of Remote Scripting 1.0b. Updated 09.10.2001. MSDN Downloads. Microsoft Corp.

 
  msdn.microsoft.com/downloads/sample.asp?url=/MSDN-FILES/027/001/734/msdncompositedoc.xml

 
  7. Ноутон П., Шилдт Г. Java 2 / Пер. с англ. СПб.: БХВ Санкт-Петербург, 2000.

 
  8. Java Remote Method Invocation Specification, Version 1.3. Sun Microsystems, Inc., 1999.

 
  java.sun.com/j2se/1.3/docs/guide/rmi/spec/rmiTOC.html

 
  9. Java Native Interface Specification, Version 1.1. Sun Microsystems, Inc., 1997. java.sun.com/j2se/1.3/docs/guide/jni/spec/jniTOC.doc.html

 
  Андрей Тимербаев, аспирант, СПбГЭТУ «ЛЭТИ», тел.: +7 (812) 374-19-21, e-mail: atimerbaev@gmx.net

 
  Райнхард Лангманн, доцент высшей технической школы г. Дюссельдорфа, тел.: +49 (211) 4351-308/319, факс:+49 (212) 446-58, e-mail: R.Langmann@t-online.de, www.telefabrik.de

22.04.2014