Особенности перехода к единой корпоративной информационной системе в ОАО "Ростовэнерго"

В 80-90-е годы прошлого века, когда компьютерная техника стала повсеместно распространятся на предприятиях в РФ, было разработано множество систем с использованием самых современных, на тот период времени инструментальных средств, таких как Clipper, FoxPro, которые позволяли автоматизировать различные виды деятельности и работать с массивами данных. Многие, из которых продолжают успешно эксплуатироваться и в настоящее время. Как правило, реинженеринг таких систем заключался в переходе на более новую версию средства разработки, на котором была написана система, например с FoxPro 2.0 на FoxPro 2.5 и далее на Visual FoxPro, с улучшением функциональности, которое позволяло реализовать новая версия инструментального средства. Однако по мере накопления больших объемов хранимой информации и переходу к централизации хранения данных, эксплуатация таких систем вызывает определенные трудности связанные с их сопровождением, синхронизацией данных, кроме того, данные системы не соответствуют требования по производительности, расширяемости и масштабируемости. Поэтому реинженеринг в этом случае, заключается в переходе на абсолютно новые архитектуры и соответственно средства разработки, которые позволяют решить описанные выше трудности.

Целью данной статьи является рассмотрение этапов реинженеринга корпоративной системы ОАО "Ростовэнерго" при переходе от многопользовательских приложений, реализованных средствами FoxPro к единой распределенной многослойной архитектуре "клиент – сервер приложений - СУБД" базирующейся на Java - технологиях.

Изначально система состояла примерно из 10 комплексов таких как АРМы "Банк", "Кадры", "Зарплата", "Склад" и т.д.), которые базировались на общем ядре АРМ "Баланс" для выполнения основных бухгалтерских операций, а также использовали свои специфичные модули бизнес логики, отчетов и таблицы для хранения данных. Весь комплекс эксплуатировался как в аппарате управления ОАО "Ростовэнерго" так и филиалах территориально находящихся в городах Ростовской области, например Восточные электрические сети (ВЭС) г. Волгодонск, Южные электрические сети (ЮЭС) г. Азов и т.п.

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

Поэтому на первом этапе было принято решение о переходе на архитектуру клиент-сервер, с использованием наиболее совместимой с FoxPro СУБД – MS SQL Server 2000 и реализации части бизнес логики в виде хранимых процедур. Данный процесс по времени занял примерно около одного года.

На втором этапе согласно распоряжению дирекции ОАО "Ростовэнерго" была реализована возможность ведения единой базы нормативно справочной информации (НСИ) и реестра контрагентов. Первая задача была решена средствами СУБД MS SQL Serever 2000 с помощью механизма репликации. В силу того, что НСИ является относительно статичной структурой, т.е. изменения и дополнения данных выполняются не часто, было принято решение делать репликацию снимка НСИ с сервера аппарата управления, которая выполняется раз в сутки в нерабочее время и передавать его подписчикам – SQL серверам филиалов. Для решения второй задачи, был задействован совершенной другой механизм, в силу того, что филиалам при заключении договоров необходимо оперативно заводить нового контрагента, в случае если он отсутствует в едином реестре, причем с данным контрагентом, договора могут заключать разные филиалы. Т.е. необходимо чтобы при вводе нового контрагента он автоматически попадал в единый реестр. Для этих целей стали использовать каркас (framework) менеджера транзакций Mule, реализовав с его помощью корпоративную шину для обмена информацией (enterprise service bus - ESB), следующим образом. При вводе нового контрагента, перед тем как выполнить внесение в единый реестр, выполняется его поиск на центральном сервере аппарата упралвения по ИНН и КПП, и если в другом филиале данный контрагент в этот день уже был заведен, то выдается его идентификатор, в противном случае он добавляется в реестр, а вечером реестр вместе с НСИ реплицируется на все филиалы. Реализация, отладка и внедрение второго этапа по времени заняли примерно около полугода.

Параллельно первому и второму этапам выполнялось проектирование и реализация многослойной архитектуры распределенной корпоративной системы. В качестве инструментальных средств выбрана Java – технология и решения базирующиеся на ней. Так как во–первых, де-факто Java – технологии – промышленный стандарт в области больших корпоративных распределенных систем, во – вторых сам язык Java и сопутствующие средства, такие как, например среда разработки NetBeans, Eclipse, средство ORM – отображения Hibernate, всевозможные менеджеры отчетов и пр. являются свободно распространяемыми. В третьих, в силу открытости данной технологии, она легко интегрируется с любой СУБД. В – четвертых, Java является аппаратно- и платформено- независимой, т.е. система реализованная с помощью Java – технологии может работать на компьютерах не только с архитектурой x86 и не только на операционной системе Windows.

Рассмотрены варианты смены платформы СУБД на более "дружественную" по отношению к Java. Был реализован ряд тестов для сравнительной оценки производительности при работе с СУБД, на основании которых в качестве альтернативы предполагается использование MySQL v.5, PostgreSQL 8.2, также отработана технология межплатформенного переноса данных.

Архитектура системы представлена на рисунке 1. Рассмотрим более подробнее каждый из уровней. Уровень базы данных отвечает за реализацию физического хранения. Во время первого и второго этапов выполнялся постоянный мониторинг работы SQL- сервера в результате которого были выявлены "узкие" места в его работе, снижавшие его производительность. Во-первых, была выполнена нормализация всех отношений и их приведение к третьей нормальной форме. Во-вторых, для снижения нагрузки на СУБД, было принято решение реализовать хранение небольших по объему, около сто записей, справочников в формате XML на Web-сервере, а при загрузке приложения выполнять анализ данного файла и заносить его содержимое в стековые структуры. Такой подход позволяет добиться повышения производительности системы, как на стороне сервера, так и на стороне клиента. В-третьих, решили отказаться от хранимых процедур на стороне СУБД и вынести их на уровень сервера приложений, так как при значительном увеличении количества пользователей (100 и более) пытающихся их одновременно выполнять существенно снижает производительность. Кроме того, специфика синтаксиса языка T-SQL MS SQL Sever не позволяет переносить хранимые процедуры на другие серверные платформы без их глобальной переработки.

Уровень сервера приложения, представляет из себя, множество слоев см. рис1., которые при необходимости для повышения производительности могут быть разнесены между несколькими серверами. Взаимодействие между уровнем баз данных и уровнем сервера приложений реализуется ORM системой – Hibernate. Это обстоятельство является одной из важных частей позволяющей довольно просто переходить от одной платформы СУБД к другой, без изменений в других слоях. Слой бизнес – логики в свою очередь условно можно разделить на несколько частей. Первая часть отвечает за работу с СУБД. Основная цель, которую пытались достичь при реализации данной части – снижение нагрузки на СУБД. Для чего все методы реализующие запросы к СУБД старались делать универсальными, т.е. не зависящими от реализации конкретного бизнес объекта, используя компонент библиотеки Hibernte – Criterion, а далее работать с полученными коллекциями, используя механизмы Java - RTTI и Reflection реализуя методы, позволяющие выбирать бизнес объекты из коллекции по различным критериям. Кроме того, при работе с большим количеством бизнес объектов (десятки и сотни тысяч) использовали отсоединенные коллекции (DetachetCriterion). Описанное выше, является второй важной частью делающей приложение независимым от платформы СУБД. Следующая составная слоя бизнес логики – специфичные методы, реализованные для конкретной задачи.

Рисунок 1. Архитектура системы

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

Слой отчетов, это фактически набор шаблонов для их построения. Отчеты строятся с использованием библиотеки JasperReport, а при реализации Web-клиента с помощью xslt преобразования, для чего реализован подслой с xslt – шаблонами.

Последний слой – Web-компонент реализован для построения web интерфейса.

На уровне клиента реализовано два типа интерфейсов – Web-клиент и полнофункциональный Swing – клиент. Так как ни одно web-приложения не обладает такими возможностями, которые предоставляет для пользователя библиотека Swing. Поэтому было принято решение для реализации относительно простых возможностей использовать Web-интерфейс, а взаимодействие посредством Swing – клиента, реализовать, используя технологию Java Web-start.

Кроме того, была разработана технология единой идентификации пользователей корпоративной системы на территории всей Ростовской области на базе быстрого и удобного механизма - LDAP сервера. На сервере, данные о пользователях разбиты в зависимости от их принадлежности к филиалу в иерархические структуры, которые повторяют организационные структуры ОАО "Ростовэнерго". Сам объект "пользователь", хранящийся на сервере содержит массу дополнительной информации, которая в том числе может использоваться для конфигурирования программ, например атрибут филиала – IP адрес сервера СУБД. Более того извлекая информацию с LDAP сервера и используя для доступа Web – интерфейс, можно формировать справочную систему, например телефонный справочник предприятия, не затрачивая дополнительных усилий.

Таким образом, был выполнен реинженеринг существующей системы и разработана архитектура и каркас (framework) приложения. Однако мы себе отчетливо представляли, что процесс перехода на новую архитектуру будет довольно сложным и долгим, так как одна из самых больших проблем связана с переносом данных в новые структуры, а малейшие изменения в существующих структурах данных могла привести к катастрофическим последствиям. Так же для коллективной разработки, использовался Subversion server(SVN). Это обеспечивает качественную связь всех разработчиков системы. В качестве клиента SVN был выбран продукт TortiseSVN.

Рисунок 2. Схема взаимодействия

1. юристов филиалов при добавлении и редактировании данных;
2. юристов филиалов при просмотре данных;
3. юристы управления при добавлении, редактировании и просмотре данных

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

Для первой задачи были проанализированы все возможные варианты ее решения. Самым правильным решением в данном случае является переход на сервер приложений и использование менеджера транзакций, например JOTM. Однако в силу целого ряда субъективных и объективных причин быстрый переход на такую архитектуру не представлялся возможным. Поэтому было принято решение использовать для двухфазной транзакции средства библиотеки Hibernate. Так же следует учитывать то, что взаимодействие клиентов аппарата управления и клиентов на филиалах с СУБД существенно отличаются, рисунок 2. Юристы аппарата управления работают только с центральным сервером, выполняя операции редактирования добавления и выборки при этом, "видя" весь реестр договоров. Юристы на филиалах при редактировании и добавлении в начале вносят их на центральный сервер, после чего происходит внесение данных на сервере филиала, а при просмотре происходит взаимодействие только с локальным сервером. Реализация данной схемы на всех уровнях архитектуры приложения выглядит следующим образом:

Уровень клиента. Приложение работает по технологии Web-start и имеет Swing- интерфейс.

Уровень сервера приложений. На основании полученного с LDAP сервера IP – адреса происходит настройка подключения к СУБД. В случае если указан IP – адрес филиала, то выполняется настройка Hibernate на создание двух фабрик сессий (SessioFactory), одна из которых создается с центральным сервером другая с локальным. При этом бизнес объект имеет два варианта мэппиинга, основное отличие которых заключается в способе получения идентификатора, на сервере значение – native, а на филиале – assign. В случае если IP – адрес центрального сервера, то соответственно создается одна фабрика сессий. Исходя из этого, работают методы сохранения и обновления бизнес объектов. При работе юристов филиала вначале изменения вносятся на центральный сервер, а затем на локальный, в случае их успешного занесения на оба сервера происходит принятие транзакций (commit) на обоих серверах, в случае возникновения каких либо проблем на одном из серверов происходит общий откат (rollback) транзакции. Следует заметить, что за время эксплуатации данной технологии в течение четырех месяцев, каких либо значимых сбоев или потери информации не было. Следующим шагом стал переход на технологию с использованием менеджера транзакции JOTM. В силу того, что отсутствует возможность установки и эксплуатации сервера приложений на каждом филиале, было принято решение использовать один сервер приложений Tomcat, на котором формировать источники данных для каждого филиала.

Уровень базы данных. Уровень базы данных на филиале и в аппарате управления отличается только способом задания уникальности идентификатора бизнес объекта. В аппарате управления установлено автоматическое увеличение на 1.

Таким образом, переход к полноценной единой корпоративной системе в РЭ - это процесс, который может растянуться на годы. Несмотря на его трудоемкость, уже сейчас очевидны его преимущества, особенно с использованием технологий от Sun Microsystems. Которые обеспечивают, оперативный доступ к любому сегменту информации на территории Ростовской области, являются свободно распространяемыми, в отличие, например от подобных технологий на базе SAP R/3.

Технологии, использованные при построении системы.

Mule (http://mule.mulesource.org/) – фреймворк для обмена сообщениями. Реализация корпоративной сервисной шины.

Hibernate – object-relational mapping (ORM) решение для языка программирования Java. Оно является свободным программным обеспечением с открытым исходным кодом. Данное решение предоставляет легкий в использовании каркас (фреймворк) для отображения объектно-ориентированной модели данных в традиционную реляционную базу данных. Способ отображения настраивается файлами *.hbm.xml, в которых с помощью xml тегов устанавливается связь между сущностями СУБД и Java-классами, и отношения (one-to-one, one-to-many и т.п.) между ними. А также конфигурационные файлы, в которых прописываются параметры конкретной СУБД.

Criteria – простая, объектно-ориентированная, интуитивно понятная, технология написания запросов.

RTTI - Динамическая идентификация типа данных (англ. RTTI, Run-time Type Information или Run-time Type Identification) — механизм, реализованный в языках программирования, который позволяет определить тип данных переменной или объекта во время выполнения программы.

Reflection (http://java.sun.com/docs/books/tutorial/reflect/index.html) – это механизм, позволяющий динамически загружать и создавать экземпляры класса, а также осуществлять доступ к полям и методам класса.

Web-start (http://java.sun.com/products/javawebstart/) – технология распространения java приложений/обновлений.

SVN – Средство коллективной разработки. Обеспечивает версионирование исходных кодов проекта.

Swing — библиотека для создания графического интерфейса на языке Java. Swing был разработан компанией Sun Microsystems. Он содержит ряд графических компонентов, таких как кнопки, поля ввода, таблицы и т. д. Swing относится к Java Foundation Classes (JFC), которая представляет из себя набор библиотек для разработки графических оболочек. К этим библиотекам относятся Java2D, Accessibility-API, Drag & Drop-API и Abstract Window Toolkit (AWT).

NetBeans, Eclipse – бесплатные распространенные IDE.

XML (http://www.w3.org/XML/) – (англ. eXtensible Markup Language — расширяемый язык разметки]) — рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML предназначен для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями.

LDAP (англ. Lightweight Directory Access Protocol — облегчённый протокол доступа к каталогам) — это сетевой протокол для доступа к службе каталогов X.500. Это относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP.

Список используемых источников

1. wikipedia.org