Software & Systems

В настоящее время во многих современных компаниях эксплуатируется большое число разнородных информационных систем (ИС) различного назначения. На определенном этапе развития информационных ресурсов компании возникает задача интеграции таких ИС по функциям и данным. В связи с этим актуальной становится разработка связующего их ПО, которое должно быть специализировано под конкретные условия компании. Одним из направлений исследований, проводимых в данной области, является изучение возможностей концепции сервис-ориентированной архитектуры (service-oriented architecture – SOA) применительно к построению корпоративных ИС и интеграции их с уже эксплуатируемыми ИС компании с целью создания единого информационного пространства.

Ключевым компонентом в SOA является сервисная шина предприятия (enterprise service bus – ESB) – связующее ПО для централизованного и унифицированного событийно-ориентированного обмена сообщениями между различными ИС или компонентами одной ИС. Среди наиболее популярных ESB можно выделить следующие продукты: Oracle Service Bus компании Oracle [1], WebSphere Message Broker компании IBM [2], ActiveMatrix Service Bus компании Tibco [3], WebMethods ESB компании Software AG [4], Sonic ESB компании Progress Software [5], JBoss ESB компании Red Hat [6]. Зачастую ESB выполняют функции не только собственно шины, но и других компонентов SOA, и даже включают средства для разработки сервисов внутри самой шины на определенном языке программирования. Для большинства компаний такие ESB оказываются избыточными по своим функциональным возможностям. Более того, все эти ESB являются коммерческими продуктами с весьма высокой стоимостью лицензий.

Сегодня усилия разработчиков ESB в рамках концепции SOA направлены на упрощение процедуры интеграции ИС при создании единого информационного пространства компании, на повышение надежности и независимости ESB от платформ и языков программирования сервисов.

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

Модель SOA информационного пространства компании

Модель SOA – это каркас для интеграции бизнес-процессов и поддерживающей их ИТ-инфраструктуры в форме безопасных и стандартизированных компонентов: сервисов, которые можно использовать многократно и комбинировать для адаптации к изменяемым приоритетам бизнеса [7]. В отличие от специализированных систем разработка ИС на основе принципов SOA позволяет эффективнее реагировать на новые рыночные возможности, изменения делового климата и законодательства. В рамках концепции SOA ИС компании разрабатывается как совокупность сервисов, каждый из которых предназначен для решения конкретной, обычно небольшой задачи. Связанные воедино в определенной последовательности сервисы образуют законченную ИС. Концепция SOA применяется в масштабах всей компании, а не отдельного подразделения [8].

Под сервисом понимается независимый программный компонент (модуль) с возможностью самоописания, выполняющий определенную бизнес-задачу (бизнес-процесс, подпроцесс, функцию) и предоставляющий некоторые функциональные возможности запрашивающей стороне (сторонней ИС или другому сервису). Чаще всего создаются веб-сервисы [7]. Слабая связность сервисов обеспечивает простую и быструю адаптацию ИС к изменению бизнес-процесса компании. Сервисы могут как работать сами по себе, так и комбинироваться с другими сервисами для создания составных (компонентных) приложений. Взаимодействуя по сети в определенной последовательности, сервисы позволяют реализовать тот или иной бизнес-процесс. Для использования сервиса необходимо следовать соглашению об интерфейсе, который является средством для предоставления возможностей сервиса внешнему миру и организации взаимодействия сервисов. В интерфейсе сервиса определены параметры обращения к нему и описан результат.

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

Третья составляющая SOA – это ESB [7]. Она является связующим ПО всех создаваемых сервисов для централизованного и унифицированного событийно-ориентированного обмена сообщениями между сервисами компании. Так, ESB ответственна за выполнение ряда задач классической интеграции: поддержка синхронного и асинхронного способов вызова служб, использование защищенного транспорта с гарантированной доставкой сообщений, поддерживающего транзакционную модель, статическая и алгоритмическая маршрутизация сообщений. Также ESB обеспечивает доступ к данным из сторонних ИС с помощью готовых или специально разработанных адаптеров, обработку и преобразование сообщений, оркестровку и хореографию служб, разнообразные механизмы контроля и управления (аудиты, протоколирование), готовые адаптеры для соединения с конкретным прикладным ПО, API для создания таких адаптеров.

Адаптеры – специфичные модули, отвечающие за интеграцию с конкретным набором сервисов. В отличие от посредника сообщений ESB не содержит логику извлечения и преобразования данных сервисов, у которых нет стандартизированных интерфейсов. Поэтому ответственность за взаимодействие с такими сервисами ложится на специальные модули – адаптеры, преобразующие данные в формат, понятный шине (например, в XML) [8]. Адаптеры необходимо разрабатывать отдельно.

Наконец, еще одна составляющая SOA – система управления бизнес-процессами (business process management suite – BPMS). Это ПО, предоставляющее возможности для запуска, координирования, управления, администрирования и отладки бизнес-процесса. При этом бизнес-процессы рассматриваются как некоторая последовательность логически связанных действий, которые преобразуют входные данные в результат или выходные данные. Иными словами, именно бизнес-процессы определяют последовательность запуска сервисов с целью решения определенной бизнес-задачи.

На основании краткого анализа составляющих SOA и их основных возможностей можно считать, что SOA представляет собой перспективную модель взаимодействия компонентов создаваемой ИС и интеграции ее с другими ИС компании. Эта модель позволяет связывать компоненты между собой с помощью четко определяемых интерфейсов, образуя единое информационное пространство компании. Причем интерфейсы не зависят от используемых в компании аппаратных платформ, операционных систем и языков программирования, применяемых для разработки компонентов ИС. Это дает возможность компонентам взаимодействовать между собой одним и тем же стандартным, но в то же время универсальным способом. Такая особенность использования интерфейсов, не зависящих от окружения и платформы, получила название слабой свя- зи [7]. Эта модель позволяет обеспечить повышенную гибкость и адаптируемость корпоративной ИС и, соответственно, единого информационного пространства в изменяющихся условиях компании, поскольку замена или модернизация одного из компонентов системы не скажется на остальных.

Современные ESB и интеграционные платформы

Сегодня в некоторых промышленных компаниях и в ряде государственных организаций ESB используются как единая точка для связи между собой большого числа ИС и приложений различного класса. Целью при этом является обеспечение гибкости масштабирования и простоты переноса единого информационного пространства компаний и унаследованных в него ИС [9]. Таким образом, ESB играет ключевую роль в интеграции ИС и создании единого информационного пространства в любой компании. Когда речь идет о современных масштабных проектах, то большое значение приобретает вопрос выбора оптимальной существующей на рынке ESB или оптимальной платформы для разработки новой ESB, обеспе- чивающей требуемые надежность и быстродействие. На данный момент существует большое число технологий, языков и библиотек для создания функциональности ESB, в частности, следующие: PHP, ASP.NET, Java Server Pages (JSP), Ruby (on Rails), Perl, Python, Flash (Action Script).

Большинство ESB строятся на схожих по функциональности компонентах и, следовательно, обладают близкими функциональными возможностями, что делает их во многих случаях взаимозаменяемыми. Эти ESB разрабатываются и крупными компаниями, и энтузиастами по принципу открытости исходного кода. Система не может считаться ESB, если не содержит функциональности по преобразованию данных в различных обменных форматах, маршрутизации сообщений и возможности создания соединений со сторонними ИС по различным протоколам [10].

Любая ESB включает готовые модули для задач интеграции (адаптеры) к популярным ИС классов ERP и MES с известными протоколами и форматами данных. Если же необходимого адаптера в ESB нет, то обычно в ней есть встроенный предметно-ориентированный язык программирования (а иногда и несколько языков), позволяющий создавать новые адаптеры с учетом желаемых аспектов взаимодействия со сторонней уникальной ИС.

Каждая ESB обязательно содержит систему очередей сообщений с поддержкой транзакций и различными моделями обмена сообщениями, например, такие модели, как отправитель-получатель, синхронный обмен, издатель-подписчик и другие. Причем поддержка обмена сообщениями во многих ESB имеет две альтернативы спецификаций – REST и SOAP.

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

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

В процессе эксплуатации ESB важным является показатель производительности, так как шина не должна быть узким местом в SOA компании. Поэтому было проведено исследование [11] наиболее известных на тот момент времени ESB (Oracle SOA Suite, Oracle Service Bus, IBM Integration Bus) с точки зрения пропускной способности, среднего времени получения и сохранения данных, среднего времени работы асинхронных сервисов, загрузки процессора в зависимости от количества потоков данных. Вывод, сделанный по результатам анализа, говорит о том, что все эти нагрузочные показатели удовлетворяют даже самым высоким требованиям, а значит, для этих продуктов можно сосредоточиться на других критериях.

Однако некоторые известные ESB не всегда в полной мере реализуют свойственные для них функции, имеют определенные ограничения. Среди таких ограничений можно отметить жесткость маршрутизации (нет гарантии доставки сообщений), отсутствие асинхронности и нереализованность многих моделей обмена сообщениями. Также может отсутствовать поддержка стандартов WSDL, BPEL, UDDI, ряда обменных форматов данных и протоколов их передачи [12]. К этому добавляется еще и слабая документированность продуктов.

Продукты корпоративных гигантов в области разработки ESB, таких как IBM и Oracle, несмотря на популярность и качество, также имеют ряд недостатков [12]: устаревшие графические интерфейсы пользователя начала 2000-х годов, большие объемы исторического кода, разные показатели эффективности версий системы (и не всегда последняя – самая лучшая). Также такие шины очень сложны в изучении и администрировании (даже настройка простых функций требует большого количества неинтуитивно понятных действий), поддерживают огромное число различных стандартов, что часто излишне, однако, может быть и плюсом в конкретных условиях больших компаний-заказчиков.

При выборе конкретной ESB или интеграционной платформы компании часто используют следующие критерии для их оценки [13].

1.    Коммерческие и технологические. Это взаимосвязанные критерии, так как определенная цена ESB подразумевает некоторое обоснование в виде объема ее функциональных возможностей. Среди таких технологических параметров можно выделить полноту поддержки функций маршрутизации сообщений по раз- личным протоколам, способность преобразования различных форматов данных, число встроенных адаптеров, удобные графические средства администрирования и конфигурирования ESB, производительность, поддержку различных протоколов по передаче данных и другие. Обычно эти критерии в окончательной оценке при выборе ESB составляют до 45 %.

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

3.    Проектные. На выбор интеграционной платформы влияют факторы, связанные с особенностями конкретной компании, например, совместимость с программными продуктами, уже существующими у нее и у компаний-партнеров, простота установки и первоначального конфигурирования. Серьезным отличием систем класса ESB является их цена. Производители включают в стоимость дополнительные адаптеры, поддержку особых протоколов и форматов данных, упрощенные инструменты для администрирования и мониторинга, графические консоли для подключения плагинов, возможность распределения нагрузки на ESB посредством использования кластера и прочие вещи, нужные не всем. Поэтому, если не хочется переплачивать за все это, то встроенный язык программирования платформы позволит восполнить недостающую желаемую функциональность за счет работы программистов компании [10]. Согласно результатам сравнительного анализа [12], ESB, созданные небольшими компаниями, по функциональности часто не хуже программных продуктов крупных корпораций, а стало быть, весьма конкурентоспособны, особенно в секторах определенной направленности, в силу ценообразования, учета особенностей отрасли и гибкого поведения на рынке.

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

На рынке ESB есть бесплатные результаты open-source проектов. Среди таких шин наиболее известны Mule ESB, JBoss, Apache ServiceMix и ряд других [14]. Сравнительный анализ по выделенным критериям отражен в таблице, где «+» в столбце означает удовлетворение критерию, «++» – удовлетворение в большей степени (чем остальные рассматриваемые аналоги), «+/–» – частичное удовлетворение критерия. Часть результатов анализа взяты из [15].

Характеристики open-source ESB

Open-source ESB characteristics

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

В таких условиях можно утверждать, что универсальных критериев выбора шины нет. Часто выбор шины или платформы для ее разработки осуществляется с учетом квалификации администратора ESB (опыт работы, язык программирования, субъективное удобство при работе), а также теми функциональными особенностями, которые необходимы компании при решении текущих задач создания единого информационного пространства.

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

Разработка корпоративных ИС для управления производством нефтегазовых компаний и создание на основе концепции SOA единого информационного пространства имеют ряд особенностей, характерных для этой отрасли.

1.    ESB должна пропускать через себя огромные объемы технологических и геолого-геофизических данных о скважинах и продуктивных пластах, а также данные подразделений промыслов на проведение геолого-технических мероприятий (ГТМ), ежегодные и ежемесячные планы геофизических, гидродинамических и промыслово-геофизических исследований скважин, ведущих к их остановкам и т.п. Частота поступления различных типов данных варьируется от 15 секунд до нескольких месяцев.

2.    Усложняет разработку единого информационного пространства компании необходимость интеграции корпоративной ИС с большим числом унаследованных ИС (число ИС в каждой компании может достигать десятков), среди которых система 3D-моделирования резервуаров месторождений, различные ИС обработки и интерпретации геолого-геофизической информации, ERP-системы и т.п. [16].

3.    ИС компании необязательно должны иметь стандартизированные интерфейсы – они могли создаваться не в рамках концепции SOA, поэтому для них должны быть разработаны адаптеры в ESB для преобразования специфических форматов данных и протоколов их передачи. Бывают и ситуации, когда ИС изначально не задумывалась открытой и не содержит API для взаимодействия с ней – такой вопрос можно решить только усилиями разработчиков этой ИС.

Перспективность использования ESB как важного компонента концепции SOA подтвер- ждается успешным примером построения корпоративной шины и единого информационного пространства ООО «Газпромтранс» – компании, входящей в состав ПАО «Газпром». Необходимо было организовать взаимодействие основной ИС компании с внешними ИС партнеров и реализовать унифицированный подход к интеграции между всеми ИС компании. Разработчики отказались от взаимодействия «точка-точка» между ИС и использования посредника сообщений в пользу сервисной корпоративной шины ввиду ее лучшей производительности, возможности мониторинга и простоты добавления новых сервисов [17].

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

Особенности специализированной ESB

В качестве инструментария для разработки специализированной ESB была выбрана платформа .NET. Она имеет мощную библиотеку классов преобразования форматов данных, протоколов взаимодействия между системами, а также несколько технологий для реализации ESB на языке C#. Для разработки специализированной ESB была выбрана технология ASP.NET MVC (model-view-controller – модель-представление-контроллер) проекта, она предоставляет каркас для разработки систем с веб-взаимодействием и уже имеет некоторые необходимые функциональные возможности, свойственные ESB, такие как маршрутизация сообщений и преобразование форматов данных между сервисами. Гибкость MVC позволяет изменять структуру ESB в соответствии с существующими требованиями компании-заказчика.

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

Чтобы осуществлять связь между СУБД и ESB, необходим посредник (адаптер). Таковым в данном случае является технология ADO.NET (Connection, Command, DataReader, DataSet, DataAdapter). Разные СУБД могут иметь разные типы данных, диалекты языка SQL, строки подключения, быть объектными и реляционными и др. ADO.NET обеспечивает ESB унифицированным интерфейсом для работы с самыми различными СУБД, среди них MS SQL Server, OLE DB (Access, DB2, MySQL), Oracle, Realm DB, Mongo DB, PostgreSQL, FireBird и другие.

Для ESB важно иметь возможность взаимодействия с ИС по протоколам передачи данных различного уровня и назначения. Сегодня в специализированной ESB реализованы сетевые протоколы Ggp, Icmp, Icmp6, Idp, Igmp, IP, IPv4, IPv6, Ipx, ND, Pup, Raw, Spx, SpxII (класс System.NET.Sockets.Socket), потоковые (TcpClient, TcpListener) и дейтаграммные сокеты (UdpClient), Http (WebClient – WebRequest, WebResponse, HttpWebRequest, HttpWeb­Response, HttpListener), почтовые протоколы (SmtpClient, POP3, IMAP), передача файлов (FtpWebRequest, FtpWebResponse). Это позволяет поддерживать интеграцию сервисов различного вида (SOAP и RESTful веб-сервисы, proxy).

Для работы со сложными объектами, передаваемыми по сети в обменных форматах, необходимо производить их сериализацию – преобразование в поток байтов. Можно использовать следующие популярные форматы: бинарный, soap, xml, json, xls, xlsx, doc, docx, cvs, txt, dbf… Для части форматов предусмотрен свой класс сериализации: BinaryFormatter, SoapFormatter, XmlSerializer, DataContractJson- Serializer.

Особенностью созданной ESB также является наличие модуля для валидации данных – значений технологических и геологических параметров. Ряд ИС в рамках интеграционного проекта содержит большие объемы подобной информации в разных единицах измерения и иногда с разными наименованиями. Поэтому часть сущностей предметной области была преобразована в структуры классов моделей. Для объектов модели указана дополнительная информация в виде атрибутов, а благодаря механизму привязки моделей можно не задумываться о сериализации данных из различных форматов в соответствующий класс.

В целом, как показывают тестовые испытания, специализированная ESB способна быстро переместить большой объем данных между двумя и более ИС, быстро загрузить большой объем данных из одного или нескольких файлов БД с возможностью преобразования данных, а также быстро настроить RESTful веб-сервис для одной или нескольких ИС компании, произвести сжатие и декомпрессию, пакетирование и архивирование, шифрование и дешифрирование данных.

Специализированная ESB поддерживает асинхронные методы. Такие методы позволяют оптимизировать производительность системы в целом, они предназначены, прежде всего, для запросов, которые могут занять продолжительное время (чтение больших объемов данных из БД, обращение к внешнему сетевому ресурсу, вычислительно сложные задачи).

На запрашиваемый маршрут в ESB можно накладывать различные ограничения, например, за счет использования синтаксиса регулярных выражений. Ограничения могут касаться метода HTTP-запроса и конкретных адресов. При этом контроллеру доступны все аспекты веб-взаимодействия (HttpContext): идентификационные данные пользователя, данные запроса (переданные параметры, куки, данные пользователя), управление ответом (кодировка, заголовки, тело ответа), данные сессии пользователя и данные маршрута.

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

Безопасность доступа обеспечивается за счет разграничения пользователей по ролям с необходимыми правами. Безопасность аутентификаций и работы пользователей в сети обеспечивает технология ASP.NET Identity.

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

Исследование эффективности специализированной ESB

По аналогии с экспериментами по определению производительности при нагрузочном тестировании трех известных ESB, приведенных в [11], авторами был проведен ряд собственных экспериментов с созданной специализированной ESB. Для экспериментов использовались сервер со схожими техническими характеристиками и аналогичные ИС, включающие также сервер БД и сервер приложений. Исследования проводились по описанному в [11] алгоритму для определения эффективности ESB. Повышение нагрузки обеспечивалось путем увеличения числа потоков, эмулирующих одновременную работу определенного числа сторонних пользователей, подключенных к шине (ИС компании и/или сервисы). Получены зависимости среднего времени работы сервиса для сохранения клиентских данных в зависимости от количества потоков (рис. 1) и загрузки процессора от количества потоков (рис. 2). На рисунках 1 и 2 для сравнения приведены аналогичные результаты из [11] для широко известных ESB – Oracle SOA Suite, Oracle Service Bus (OSB) и IBM Integration Bus.

Из рисунков 1 и 2 видно, что показатели производительности при нагрузочном тестиро- вании для разработанной специализированной ESB лучше, чем у продуктов компании Oracle (шины Oracle SOA Suite и OSB), однако хуже, чем у шины компании IBM. Это говорит о том, что созданная ESB вполне конкурентоспособна на рынке по критерию производительности.

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

Использование ESB в компаниях нефтегазовой отрасли

В настоящее время специализированная ESB внедрена в компаниях «Востокгазпром» и «Томскгазпром». На рисунке 3 приведены используемая в «Томскгазпроме» специализированная ESB, созданные комплексные сервисы и унаследованные ИС (показана только их часть). Среди сервисов, связываемых шиной и реализующих бизнес-процессы управления производством компании, выделены сервисы управления ГТМ на фонде скважин [18]: сбор исходных данных по фонду скважин, отбор скважин-кандидатов для проведения ГТМ, выбор вида ГТМ на таких скважинах, оценка технологической и экономической эффективности ГТМ, планирование работы бригад капитального ремонта скважин. Эти сервисы являются компонентными, они декомпозируются на сервисы, реализованные на различных языках программирования и платформах (среди них ASP.NET, NODE.JS).

Одной из составляющих модели SOA, используемой в компании, является BPMS. В качестве BPMS выбрана ELMA BPM [19]. Через ESB осуществляется взаимодействие сервисов ИС между собой и с внешними по отношению к созданным сервисам, унаследованными ИС компании. В качестве примера внешних ИС на рисунке 3 приведены две системы (они наряду с BPMS расположены выше сервисной шины). Первая из этих систем – MES (manufacturing execution system) – предназначена для оперативного управления производственными процессами нефтегазодобывающей компании. Вместо нее в некоторых компаниях используются более простые системы диспетчерского управления. Из таких систем представленные сервисы получают данные об остановках скважин, времени их простоя и т.п. Другим примером внешней ИС является система обработки геолого-геофизической информации, из которой сервисы получают, например, значения геологических параметров продуктивных пластов. В компании имеется также ряд ИС для гидродинамического моделирования нефтяных и газовых резервуаров, интерпретации геологических данных и построения геологических разрезов и т.п.

Унаследованные ИС необязательно имеют стандартизированные интерфейсы, так как они создавались не в рамках концепции SOA, поэтому для них реализованы адаптеры сервисной шины.

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

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

Заключение

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

Такая специализированная ESB создана с использованием технологии ASP.NET MVC проекта на платформе .NET. При этом разра- ботаны соответствующие модули ESB, отвечающие функциональным и технологическим требованиям ESB со стороны компаний нефтегазовой отрасли. Эта ESB может легко конфигурироваться и позволяет создать интеграционную шину с учетом специфики компании. Результаты исследований эффективности и применения созданной ESB в двух добывающих компаниях нефтегазовой отрасли указывают на простоту интеграции с ее помощью новых сервисов и унаследованных в компании ИС, а также подчеркивают ее высокую производительность.

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

Исследования были поддержаны грантом РФФИ № 18-47-700010р_а.

Литература

1.    Oracle Service Bus. URL: http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html (дата обращения: 11.11.2018).

2.    WebSphere Message Broker. URL: https:// www.ibm.com/support/knowledgecenter/en/SSKM 8N/mapfiles/product_welcome.html (дата обращения: 11.11.2018).

3.    ActiveMatrix Service Bus. URL: https://docs. tibco.com/pub/activematrix_service_bus/3.3.0_september_2013/doc/pdf/tib_amx_concepts/tib_amx_ concepts.pdf (дата обращения: 11.11.2018).

4.    WebMethods ESB. URL: https://www.soft- wareag.com/resources/Enterprise-service-bus (дата обращения: 11.11.2018).

5.    Sonic ESB. URL: http://www.progress-tech. ru/products/sonic/esb (дата обращения: 11.11.2018).

6.    JBoss ESB. URL: http://jbossesb.jboss.org (дата обращения: 11.11.2018).

7.    Juric M. SOA Approach to Integration. Birmingham: Packt Publ. Ltd., 2007, 366 p.

8.    Козлецов А.П., Решетников И.С. Современные способы организации обмена данными с системами управления // Информационные технологии в проектировании и производстве. 2010. № 2. C. 17–23.

9.    Выбор интеграционной платформы: технологии и критерии. URL: https://www.epam-group.ru/ideas/white-papers/integration-platform-choice (дата обращения: 11.11.2018).

10. Обзор ESB-систем ServiceMix и Fuse. URL: https://habr.com/post/311540/ (дата обращения: 11.11.2018).

11. Все шины хороши – выбирай на вкус. URL: https://www.softlab.ru/blog/issledovaniya/5494/ (дата обращения: 11.11.2018).

12. Сравнение интеграционной шины Media- tor ESB и существующих на рынке решений. URL: http://www.dasystems.ru/esbComparison.html (дата обращения: 11.11.2018).

13. Корпоративная сервисная шина – «бюджетный» подход к решению задач интеграции. URL: http://citforum.ru/internet/webservice/esb/ (дата обращения: 11.11.2018).

14. Top Open Source ESB Projects. URL: https:// dzone.com/articles/top-open-source-esbs (дата обращения: 11.11.2018).

15. Выбор корпоративной сервисной шины с открытым исходным кодом в составе ИС на основе сервис-ориентированной архитектуры. URL: http://www.ict.edu.ru/vconf/files/11590.pdf (дата обращения: 11.11.2018).

16. Марков Н.Г. Информационно-управляющие системы для газодобывающего производства. Томск: Изд-во ТПУ, 2016. 261 с.

17. Опыт внедрения ESB (интеграционной шины) в ПАО «Газпром нефть». URL: https:// infostart.ru/public/925150 (дата обращения: 11.11.2018).

18. Markov N., Vasileva E., Evsyutkin I. The intellectual information system for management of geological and technical arrangements during oil field exploitation. JPCS, 2016, vol. 803, no. 1. URL: https://iopscience.iop.org/article/10.1088/1742-65 96/803/1/012093 (дата обращения: 11.11.2018).

19. Евсюткин И.В., Марков Н.Г. Выбор системы управления бизнес-процессами для нефтегазодобывающего предприятия // Молодежь и современные информационные технологии: сб. тр. XV Междунар. науч.-практич. конф. Томск: Д-Принт, 2018. С. 237–238.

References

1. Oracle Service Bus. Available at: http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html (accessed November 11, 2018).
2. WebSphere Message Broker. Available at: https://www.ibm.com/support/knowledgecenter/en/
   SSKM8N/mapfiles/product_welcome.html (accessed November 11, 2018).
3. ActiveMatrix Service Bus. Available at: https://docs.tibco.com/pub/activematrix_service_bus/3.3.0_
   september_2013/doc/pdf/tib_amx_concepts/tib_amx_concepts.pdf (accessed November 11, 2018).
4. WebMethods ESB. Available at: https://www.softwareag.com/resources/Enterprise-service-bus (accessed November 11, 2018).
5. Sonic ESB. Available at: http://www.progress-tech.ru/products/sonic/esb (accessed November 11, 2018).
6. JBoss ESB. Available at: http://jbossesb.jboss.org (accessed November 11, 2018).
7. Juric M. SOA Approach to Integration. Birmingham, Packt Publ. Ltd., 2007, 366 p.
8. Kozletsov A.P., Reshetnikov I.S. Modern ways of organizing data exchange with control systems. Information Technology of CAD/CAM/CAE (ITDP). 2010, no. 2, pp. 17–23 (in Russ.).
9. The Choice of an Integration Platform: Technologies and Criteria. Available at: https://www.epam-group.ru/ideas/white-papers/integration-platform-choice (accessed November 11, 2018).
10. Overview of ServiceMix and Fuse ESB Systems. Available at: https://habr.com/post/311540/ (accessed November 11, 2018).
11. All Service Buses are Good, Choose to Your Taste. Available at: https://www.softlab.ru/blog/issledovaniya/5494/ (accessed November 11, 2018).
12. Comparison of Mediator ESB integration bus and existing solutions at the market. Available at: http://www.dasystems.ru/esbComparison.html (accessed November 11, 2018).
13. A Corporate Service Bus as an Affordable Approach to Solving Integration Problems. Available at: http://citforum.ru/internet/webservice/esb/ (accessed November 11, 2018).
14. Top Open Source ESB Projects (IBM). Available at: https://dzone.com/articles/top-open-source-esbs (accessed November 11, 2018).
15. Selecting an Open Source Enterprise Service Bus as Part of an Information System Based on a Service-Oriented Architecture. Available at: http://www.ict.edu.ru/vconf/files/11590.pdf (accessed November 11, 2018).
16. Markov N.G. Information and Control Systems for Gas Production. Tomsk, 2016, 261 p.
17. Implementing ESB (integration bus) in Gazprom Neft PJSC. Available at: https://infostart.ru/public/925150 (accessed November 11, 2018).
18. Markov N., Vasileva E., Evsyutkin I. The intellectual information system for management of geological and technical arrangements during oil field exploitation. J. of Physics: Conf. Series. 2016, vol. 803, no. 1. Available at: https://iopscience.iop.org/article/10.1088/1742-6596/803/1/012093 (accessed November 11, 2018).
19. Evsyutkin I.V., Markov N.G. Choosing a business process management system for an oil and gas producing enterprise. Youth and Modern Information Technologies: Proc. 15th Intern. Sci. and Pract. Conf. for Students, Postgraduates and Young Scientists. 2017, Tomsk, D-Print Publ., 2018, pp. 237–238 (in Russ.).