CC BY
74
УДК 519.6
Интеграция "Open source" - продуктов с операционной системой, позволяющих достигать эффект кросс-платформенности и кросс-браузерности
И.Н. Воронкина, преподаватель, Ставропольский региональный колледж вычислительной техники и электроники Д.Е. Белов, к. б. н.,
А.Ф. Шалин, гл. специалист по информационной безопасности
Для разработки информационно-вычислительных систем в современных условиях необходимо учитывать мировой опыт в решении этих проблем. Как показывают проведенные исследования, в мировой практике образовалось несколько направлений разработки программного обеспечения, которые, в свою очередь, с течением времени преобразовались в отдельные технологии.
В ряд перспективных технологий заложена концепция «гибкой» разработки приложений, предусматривающая взаимозаменяемость крупных блоков, таких как система управления базами данных, уровень бизнес-логики, уровень представления. Именно эти идеи лежат в основе кросс-платформенности программного обеспечения.
Под кросс-браузерностью понимается свойство сайта отображаться и работать во всех популярных браузерах идентично, то есть способность отображать материал с одинаковой степенью читабельности.
Термин кросс-браузерность обязан своим появлением так называемой «браузерной войне», которая велась компаниями Microsoft и Netscape Communications в 1990-х годах. По мере развития конкуренции производители стали внедрять собственные функции для браузеров, что привело к особенностям отображения и различиям в работе.
Итогом «браузерной войны» стала полная победа компании Microsoft с браузером Internet Explorer, однако компания Netscape Communications открыла исходные коды своего браузера Netscape Navigator.
Открытые исходные коды браузера Netscape Navigator позволили развиваться ряду проектов, наиболее успешным из которых стал браузер Mozilla Firefox. Кроме того, за последние 10-15 лет был выпущен ряд браузеров, которые довольно прочно закрепились на рынке, к таким браузерам можно отнести следующие: Google Chrome, Opera, Safari.
Преодоление сложностей интеграции средств разработки, позволяющих создавать приложения, обладающие эффектом кросс-платформенности и кросс-браузерности, и стало центральной задачей данного исследования.
В результате проделанной работы был изучен ряд среды разработки JAVA-приложений (Integrated Development Environment -
далее IDE). Основными критериями оценки были доступность и расширяемость (возможность подключения дополнительных модулей для работы с базами данных).
После проведения анализов, тестов, изучения конъюнктуры рынка мы пришли к выводу, что для решения наших задач наиболее подходящей является IDE Eclipse.
Eclipse - это расширяемая, «Open source»-интегрированная среда разработки. Этот проект был запущен в ноябре 2001 года, когда IBM выделили исходный код из Websphere Studio Workbench, ценой в 40 миллионов долларов, и сформировали Eclipse Consortium для управления разработкой этого инструмента.
При выборе системы управления реляционными базами данных (далее - СУДБ) мы руководствовались такими принципами, как кросс-платформенность, возможность использования сетевых приложений, поддержка стандартов SQL. В результате исследований был выявлен ряд систем коммерческих, бесплатных и условно бесплатных, таких как: IBM DB2, IBM Informix, Oracle, Cache, CouchDB, CUBRID, DB2, Firebird, H2, Informix, Ingres, InterBase, MSDE, MS SQL Server, Mnesia, MongoDB, MySQL, mSQL, Oracle, Pervasive SQL, PostgreSQL, Redis. Sybase ASE, Sybase ASA, Sybase IQ, Teradata, ЛИНТЕР, DataFlex, dBase, MS Access, OpenOffice.org Base, Paradox, Sav Zigzag, Fire Bird.
Исходя из поставленных целей и руководствуясь основными принципами проекта, которые должны обеспечить востребованность и конкурентоспособность программного обеспечения, разработанного в результате его реализации, нами как наиболее перспективная СУБД была выбрана MySQL.
Необходимо также отметить СУБД Fire Bird, которая также является кросс-платформенной и бесплатной, однако одним из ее преимуществ перед MySQL является мощный встроенный язык PSQL. Кроме того, Fire Bird является более компактной, что может существенно облегчить удаленные манипуляции с этой СУДБ.
Тем не менее фреймворки, которые мы собираемся использовать в своей работе, достаточно плохо поддерживают логику, задействованную на сервере баз данных. Таким образом, мы склоняемся к переносу основной логики с уровня базы данных на уровень приложения. В этом случае у СУДБ MySQL есть одно мощное преимущество, которое выражается в масштабируемости базы данных путем разделения пишущих и читающих реплик.
Это первый аспект, который подталкивает нас перенести основную часть логики на уровень приложения. И второй: если вся логика будет находиться в приложении, то для того, чтобы поменять базу данных, не потребуется применять больших усилий. Например, если в будущем нам, потребуется Oracle или что то еще, тот же Fire Bird.
Интеграция MySQL 5.5.
Данная операция проводилась по следующему алгоритму: загрузка дистрибутива, запуск инсталлятора, выбор кодировки и типа таблиц, установка логина и пароля администратора, выбор порта.
В результате проведенных манипуляций мы получили следующую конфигурацию MySQL, параметры которой хранятся в файле my.ini : [client]
port = 3306
socket = /tmp/mysql.sock
[mysqld]
port = 3306
socket = /tmp/mysql.sock
back_log = 50 max_connections = 100 max_connect_errors = 10 default-storage-engine = InnoDB [mysqldump] quick
max_allowed_packet = 16M open-files-limit = 8192
После установки проводилось тестирование на работоспособность. При помощи командной строки запускали программу mysql.exe, находящуюся в каталоге \bin с параметрами логина и пароля пользователя. Затем использовали команду «show databases» чтобы убедиться в правильности установки основных баз данных, часть из которых необходима для корректной работы. Результат обработки команды «show databases» утилитой mysql.exe представлен на рисунке
1.
ПЯ Администратор Командна» строка • mysql -и root
itt ДПЇ і їіиїм dAtaliaseJi:
' Dutabfts*
\ it f о l-ftftt iim _Sc he mrt ! I hjtql
t lirformnnUe.Stliemfl ! ! : I test !
t cw r Id
Рисунок 1 - Результат обработки команды «show databases» утилитой mysql.exe.
Интеграция JAVA
Алгоритм: загрузка дистрибутива, запуск инсталлятора jdk и jre, выбор директории установки, настройка переменных среды.
Тест - запускаем из командной строки команду «java -version». Если установка и настройка JAVA прошли успешно, то мы должны увидеть информацию о версии среды выполнения, представленную на рисунке 2, в нашем случае это версия 1.6.0_27,.
яЩ Администратор; Командна« строка
C:\Users\Adn in > java -version jawa version *1.6.8„27"
Java(TM) SE Runtime Environnent (build 1.6.8_27-b07>
Java HotSpot(TM) Client UM (build 20.2-b06, mixed node, sharing)
C:\Users\fldnin >_
Рисунок 2 - Результат обработки команды ««java-version».
Интеграция Eclipse Алгоритм: загрузка дистрибутива, запуск инсталлятора, выбор директории установки, настройка переменных среды окружения.
Для тестирования создадим простую программу, состоящую из одного класса, результатом которой будет вывод на консоль «Привет Ява!».
nie bdrt bource Ketactor Navigate bearch Project Kun Window Help
4P C3
File Edit Source Refactor
гЗ csa
Navigate Search Project Run Window Help
^ - о ~ ■ œ ~ & ев- ~ œ
1^^ HelloTest.java НЁЗЙЬ.__________
package ru.ovis.hello;
: public class HelloTest f
public static void main(String[] args) { System.owt.println("Привет Ява ! ”);
і* Problems Javadoc lü¿. Declaration UJ Console S3
terminated» HelloTest [Java Application] C:\Program Files\Java\jdkl.6.0_27\bin\javaw.exe (13.11.2011 14:28:24) Привет Ява !
Рисунок 3 - Исходный код и результат выполнения JAVA-программы.
Интеграция Tomcat
Алгоритм: загрузка дистрибутива, запуск инсталлятора, выбор директории установки, настройка переменных среды.
Для проведения теста запускаем Tomcat и вводим в адресной строке браузера localhost:8080. Если все прошло удачно, то мы должны увидеть примерно следующее.
- J - 1 [ IXltnberr«« S.. V) ж i ~ -ж I 1 1 *4 ' !_ “ * -
14 f Apache / Tomcat Aoache Software Foundation
—- http://www apache org/ \f you're seeing mis page* via a web browser, at means you've setup Tomcat successfully. Сongraitulatlond As you may try now. tha-5. <s th« o^rauii Tomcat noma pao» t can be found on trie tocal file-system at
Ad ministrar ton
Tûmcat rvtenaaex
Рисунок 4 - Результат тестирования Tomcat.
Для генерации SQL-запросов, позволяющих разворачивать базу данных на локальных и удаленных компьютерах, была разработана программа на языке Java, использующая технологию ORM (англ. Objectrelational mapping, рус. Объектно-реляционное отображение). Основной проблемой, с которой мы столкнулись при разработке, было перенесение принципов формирования данных в реляционной модели в объектно-ориентированную, так как в объектно-ориентированной модели объекты в программе представляют объекты из реального мира.
Суть проблемы состоит в преобразовании таких объектов в форму, в которой они могут быть сохранены в таблицах базы данных и которые легко могут быть извлечены в последующем, с сохранением свойств объектов и отношений между ними. Эти объекты называют «хранимыми» (англ. persistent).
Для достижения эффекта кросс-платформенности был использован открытый фреймворк «Hibernate», в качестве конкурентного провайдера рассматривался «EclipceLink». Основным его преимуществом перед «Hibernate» является то, что «EclipceLink» позволяет держать сессию в открытом состоянии. Однако, ввиду расширенных возможностей «Hibernate», которые представлены более «мягкими» инструментами работы с базой данных, пришлось выбрать именно этот фреймворк.
Однако при запуске программы на движке FireBird возникла следующая проблема: генерация SQL - кода не происходила и возникала ошибка - «org.hibernate.exception.GenericJDBCException: could not execute query; nested exception is javax. persistence. PersistenceException: org.hibernate. exception. GenericJDBCException: could not execute query».
В результате проведенного анализа было установлено, что в системной таблице FireBird - «RDB$FIELD_NAME» содержится значение CHAR(31). А это означает, что длина имени поля не может превышать 31 символ. В нашей программе самым большим полем являлось organizationIssuingThePassport в классе SheepOwner, однако длина этого поля составляет 30 символов.
Почему же FireBird отказывается с ним работать? Ответ на этот вопрос кроется в отдельных аспектах реализации фреймворка «Hibernate». А именно, если обратить внимание на структуру SQL - кода, который образуется из pojo-объектов в java-программе, то мы увидим, что organizationIssuingThePassport преобразуется в
organization_issuing_the_passport. А это уже 33 символа.
Выход из этого положения был найден при изучении документации к «Hibernate», а именно, была обнаружена аннотация @column, которая позволяет реализовать другое имя для поля в базе данных. Например, поле organizationIssuingThePassport класса SheepOwner было модифицировано следующим образом:
@NotNull
@Size(max = 150)
@Column(name= "orgJs_Pass")
private String organizationIssuingThePassport.
Однако, если мы внимательно всмотримся в SQL-код, то можем убедиться, что механизм присвоения идентификационного номера в MySQL и FireBird работает неодинаково.
Суть проблемы состоит в том, что MySQL по умолчанию создает Id в рамках каждой отдельной таблицы, то есть каждая запись, добавленная в таблицу, будет увеличена на единицу. Однако FireBird для генерации первичных ключей использует общий генератор «HIBERNATE_SEQUENCE», таким образом, каждая запись, добавленная в любую из таблиц базы данных, будет увеличивать счетчик генератора на единицу. Это означает, что при дефолтных настройках совместимости данных из MySQL и FireBird достигнуть будет достаточно сложно.
Тем не менее этих проблем удавалось избежать при изменении параметров аннотации @GeneratedValue(strategy =
GenerationType.AUTO) на SEQUENCE для MySQL и на TABLE для FireBird.
Литература:
1. Абонеев, В.В. Методика оценки мясной продуктивности овец /В.В. Абонеев, Ю.Д. Квитко, И.И. Селькин и др. //Ставрополь, 2009. -34с.
2. Абонеев, В.В. Перспективные направления селекции овец в условиях рыночной экономики /В.В. Абонеев, А.Н. Соколов //Овцы, козы, шерстяное дело. -2007. -№ 1. -С. 7-11.
3. Абонеев, В.В. Приемы и методы повышения конкурентоспособности товарного овцеводства /В.В. Абонеев, Л.Н. Скорых, Д.В. Абонеев //ГНУ СНИИЖК, г. Ставрополь. -2011. -337с.
4. Абонеев, В.В. Развитие тонкорунного овцеводства в России /В.В. Абонеев, В.В. Марченко, А.И. Суров, А.А. Пикалов, А.И. Ерохин, С.А. Карасев //Овцы. Козы. Шерстяное дело. -2012. -№ 2. - С.6-13.
5. Абонеев, В.В. Стратегия развития овцеводства в Российской Федерации /В.В. Абонеев //Достижения науки и техники АПК. -2008.-№10. -С.37-39
6. Василенко, В.Н. Племенная база овцеводства Ростовской области. /В.Н. Василенко, Ю.А. Колосов //Зоотехния, 2002.-№8. -С.9-12.
7. Завгородняя, Г.В. Мясная продуктивность баранчиков разных генотипов и уровней кормления /Г.В. Завгородняя, Ю.Д. Квитко, И.И. Дмитрик, И.П. Будякова, И.Н. Шарко // Овцы. Козы. Шерстяное дело. -2012. -№ 2 -С.42-44.
8. Квитко, Ю.Д. Мясная продуктивность и качество мяса молодняка овец разного происхождения /Ю.Д. Квитко, А.В. Скокова, С.Ф. Силкина //Овцы. Козы. Шерстяное дело. -2012. -№ 2. -С. 39-41.
9. Квитко, Ю.Д. Проблемы и новые подходы в организации производства баранины /Ю.Д. Квитко //Сборник научных трудов Ставропольского
научно-исследовательского института животноводства и кормопроизводства. -2005. -Т.1. -№2. -С.3-7.
10. Ковалюк, Н. В. Молекулярно-биологические методы для оздоровления стад крупного рогатого скота от лейкоза /Н.В. Ковалюк //Ветеринария, 2008. -№2. -С.22-26.
11. Ковалюк, Н.В. Использование генетического маркера BOLA-DRB3 для оптимизации селекционного процесса при скрещивании /Н.В Ковалюк, В.Ф. Сацук //Молочное скотоводство.-2010.-№2.-С.10-12.
12. Ковалюк, Н.В. Методические рекомендации по использованию маркера ВоЬА DRB3 в селекционно-племенной работе с крупным рогатым скотом: Рекомендации СКНИИЖ /Н.В Ковалюк, В.Ф. Сацук //Краснодар, 2010. -24с.
13. Ковалюк, Н.В. Современные методы диагностики лейкоза крупного рогатого скота /Н.В. Ковалюк, В.Ф. Сацук, Е.В. Мачульская //Ветеринария Кубани, 2007. -№1. -С.18-20.
14. Колосов, Ю.А. Информационное сопровождение селекционного процесса в овцеводстве: учебное пособие /Ю.А.Колосов, А.И.Бараников,
B.Н.Василенко, Н.В. Михайлов //Изд-во Донского ГАУ, пос. Персиановский, 2012. -55с.
15. Колосов, Ю.А. Модель организации селекционно-племенной работы в овцеводстве с применением метода зависимых уровней отбора /Ю.А. Колосов, И.В. Засемчук //Новочеркасск, 2008.-С.76.
16. Колосов, Ю.А. Продуктивность молодняка породы советский меринос и её помесей с эдильбаевскими баранами /Ю.А. Колосов, С. В. Шихов //Овцы, козы, шерстяное дело. -2006. -№3. -С. 7-10.
17. Николаенко, В.П. Бактерицид - антисептическое средство нового поколения для птицеводства /В.П. Николаенко //Ветеринария, 2003. -№3. -С.48-51.
18. Николаенко, В.П. Высокоэффективные препараты /В.П. Николаенко //Птицеводство, 1997. -№2. -С. 25-26.
19. Новопашина, С.И. Переваримость питательных веществ рациона молочными козами при разном уровне протеина /С.И. Новопашина, Ю.Д. Квитко, М.Ю. Санников, Е.И. Кизилова //Овцы. Козы. Шерстяное дело. -2012. - № 2. - С. 64-67.
20. Ольховская, Л. В. Иммуногенетический анализ в селекции коз /Л.В. Ольховская, Л.Н. Чижова и др.//Ставрополь. ВНИИОК, 2000. -С. 3-11.
21. Тимошенко Н.К. Рынок шерсти: состояние и тенденции развития /Н.К. Тимошенко, В.В. Абонеев //Овцы, козы, шерстяное дело, 2012. -№2. -
C.50.
22. Тимошенко, Н.К. Состояние и перспективы развития первичной обработки шерсти /Н.К. Тимошенко //Овцы, козы, шерстяное дело, 2007. -№ 4. -С.46-50.
23. Чижова, Л. Н. Биохимические тест-системы, генетические маркеры продуктивности, их использование в селекции овец /Л.Н. Чижова //Автореф. дисс.... д-ра с.-х. наук. -Ставрополь, 2004. -58с.
24. Чижова, Л.Н. Методические рекомендации комплексной оценки крупного рогатого скота мясных пород по фенотипу и генотипу /Л.Н. Чижова и др. //Ставрополь, 2008. -52.
