Технология Клиент-Сервер 1998'3
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Java со стороны сервера

Возможно, вы слышали разговоры о том, что для управления базами данных наиболее пригодным является Java. Говорят, что есть продукт, предлагающий в дополнение к SQL стандарт языка программирования, то есть то, что нужно отрасли серверов баз данных, и что это — язык Java. В действительности, это не просто разговоры.

При такой оценке был бы полезен некоторый скептицизм. Несмотря на утверждение рьяных сторонников Java, этот продукт не всемогущ. Например, что может сделать объектно-ориентированное программирование для серверов реляционных баз данных — Oracle, Informix или Sybase? Ответы на этот вопрос появляются при учете того, что, как код ядра Java (классы Java), так и компилятор (Java Virtual Machine, JVM) присутствуют на почти всех компьютерах, подключающиехя к Интернет с помощью браузеров Netscape Navigator и Microsoft Internet Explorer. Преимущества такого распределения в том, что программы Java, написанные для среды браузера, очень невелики, и этот код будет работать везде, где работает браузер (по крайней мере, теоретически).

Многие из направлений использования Java в управлении базами данных определяются возможностями модели распределения Java - небольшими портативными реализациями, пригодными для работы с Интернет. Это - одна из причин, почему многие ранние продукты нацелены на системный рынок встраиваемых продуктов. Такие продукты имеют небольшой размер, им нужно не более 2 Мб RAM и в качестве фоновых серверов баз данных они легко встраиваются в другие программные продукты. Например, поставщик приложений Janna Systems (www.janna.com), разрабатывающий приложения для контактного управления, решил использовать встраиваемые Java-серверы баз данных (в данном случае, Oracle Lite). Таким поставщикам, как Janna, необходимы согласованность со своим Java-кодом, портативность приложений и возможность перемещения управления данными между клиентом и сервером.

Большинство крупных разработчиков реляционных СУБД, такие, как Oracle, Sybase, IBM и Informix предлагают различные варианты использования Java в серверах баз данных. Возможно, точнее было бы сказать, что эти поставщики экспериментируют с Java и процессорами баз данных. За исключением IBM, которая уже встроила Java в свой DB2 Universal Server, другие производители, перед включением Java в свои основные сервера, используют ее в небольших продуктах. Oracle включил в Oracle Lite 3.0 многое из Java, а Sybase выпустила новый продукт SQL Anywhere (называемый сейчас Adaptive Server Anywhere), в котором используются многие возможности Java.

Такая благосклонность к Java, обычно совмещенная с другими средствами работы с Web, часто интерпретируется как отчаянная попытка перенести реляционные системы в объектный мир Интернет. Конечно, многие системы реляционных баз данных используют объекты, хотя и делают это не совсем изящно. Реляционные и объектные модели не полностью совместимы. Однако, связь между данными и объектами существует. В объектно-ориентированном случае, данные заключены в самих себя, инкапсулированы в объекте. Чаще всего данные поступают из какого-то внешнего источника, обычно - базы данных. Это лишний раз подтверждает, что объектно-орентированное программирование на самом деле не зависит от того, как объекты получают свои данные. Java-подход и мир реляционных баз данных, тем не менее, сосуществуют достаточно хорошо.

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

Когда дело доходит до Java, первое, с чем имеет дело большинство систем реляционных баз данных - это JDBC. Как и вездесущий ODBC, по образцу которого создан JDBC, последний представляет собой API и содержит набор драйверов для определенных баз данных. Он может соединяться с чем угодно, понимающим команды SQL и даже кое с чем безмозглым, типа текстовых файлов ASCII. Драйверы JDBC писать не сложнее, чем драйверы ODBC (впрочем, из этого не следует, что их просто писать), но, как и в ODBC, драйвер может получиться хорошим и не очень. Преимуществом JDBC при программировании в Java является то, что вы можете модифицировать или расширять классы доступа к данным в зависимости от потребностей приложения. Сейчас, если говорится, что продукт поддерживает Java, это значит, что, как минимум, есть поддержка JDBC.

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

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

Такой тип хранения объектов, называемый репозиторий объекта (object repository), становится стандартом для объектно/реляционных и объектно-ориентированных СУБД. Возможность сохранения объектов вместе с относящимися к ним метаданными является идеальной для систем, внедренных в брокеры объектов, сред разработки приложений и другого программного обеспечения, хранящего объекты Java.

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

Несмотря на то, что DB2 Universal Database не переписан в Java, IBM первая среди крупнейших поставщиков СУБД использовала Java в своем основном продукте. Universal Database - это объектно/реляционная СУБД производства IBM, который компания искусно вставила в свой продукт, без ущерба злосчастному Informix Universal Server. IBM реализовала его, внедрив поддержку смешанных типов данных, что было необходимо для использования возможностей Java и Web.

Для обеспечения динамических SQL-запросов, DB2 Universal Database поддерживает JDBC API. Кроме того, несмотря на то, что триггеры Java включены не были, поддерживаются хранимые процедуры и пользовательские функции, написанные на Java. Приложение Java может подключаться к DB2 посредством Client Application Enabler, работающего со стороны клиента. DB2 поддерживает апплеты Java без необходимости использования Enabler. В связке с DB2 находится Net.Data производства IBM - менеджер приложения среднего уровня, который может координировать DB2 с процессами сервера и клиента, в том числе и с Java-апплетами со стороны серверов.

Oracle сильно поумерил свои амбиции относительно проекта Seconda - главного включения объектно-ориентированной технологии в основную систему базы данных Oracle. Возможно, его ценность была сильно преувеличена, и, помимо этого, он не был Java-ориентирован. К счастью для Oracle, существует множество способов перейти к объектно-ориентированной технологии, включая “подтяжку” не очень удачного продукта. Именно этим интересен Oracle Lite 3.0. Это - попытка включить объекты и программирование на Java в среду сервера базы данных без пересмотра и усложнения основной системы базы данных Oracle.

Вы могли обратить внимание на номер версии - 3.0. Это не говорит о том, что Oracle Lite является Java-продуктом третьего поколения. Предыдущий продукт назывался Personal Oracle Lite, являлся сервером базы данных для одного пользователя и продвигался на рынке как передовое решение тяжеловесной системы Oracle 7. После этого, в декабре 1997 года, Oracle выпустил Oracle Lite 3.0, представляя его как сильно измененный Java-ориентированный продукт.

Новый Oracle 3.0 сохранил многие из своих возможностей управления данными, в особенности средства копирования данных и автоматическое подключение к Oracle 7 и Oracle 8. Существенное изменение претерпели новые возможности, связанные с Java. Среди них поддержка JDBC, возможность создания триггеров и хранимых процедур в Java, возможность использования классов доступа Java для хранения Java-объектов и управление данными посредством приложения браузера, поддерживающего Java. Для работы Oracle Lite 3.0 необходимо: 1 Мб RAM и менее 2,5 Мб дискового пространства.

Одним из достоинств Oracle 3.0 является реализация хранимых процедур и триггеров баз данных. (См.рис.1). Приведем краткий пример хранимой процедуры, реализованной в Oracle Lite:

Public class Employee {
Public static void Pay_Salary
  ( connection conn, String ssno,
  float sal, String bankID)
    {/* deposit code goes here */
    }
}

ALTER TABLE EMPLOYEE ATTACH
  SOURCE “Employee” IN ‘/temp’;

SELECT EMPLOYEE.”Pay_Salary”
  (‘123456789’,‘222-34-4425’
,60000.00,’10-21-BA-74’)
FROM EMPLOYEE;

Хранимым процедурам уровня таблицы даже не нужно создавать объекты Java. Они могут быть вызваны обращением к ним - имя_таблицы.имя_метода вместе с аргументами метода.

Процедуры уровня строк нуждаются в Java-объекте, в качестве аргументов которого берутся значения строк. Эти вызовы встроены в оператор SELECT (в предыдущем примере). В отличие от ORACLE PL/SQL, хранимые процедуры и триггеры не программируются в среде базы данных. Они могут программироваться в любом выбранном вами средстве.

Хранимые процедуры и триггеры на Java в преломлении Oracle Lite

Java-реализация хранилища объектов в Oracle также весьма интересна, поскольку для доступа к метаданным, хранимым в базе данных, он использует набор классов Java. Эти Java-классы доступа (Java Access Classes) предоставляют прямой путь к данным - нет необходимости преобразовывать объектные данные в реляционные, что сберегает время программиста. Классы доступа имеют и другие сложные механизмы, включая запрос и создание схемы данных, управление персистентными объектами (persistent objects), обращение к хранимым процедурам Java, расширение свойств ACID для осуществления транзакций, и генерация класса заместителей Java.

Заместители используются для организации прямого интерфейса с классами Java, что описывается моделью данных, хранимых в базе данных Oracle Lite. Это устраняет необходимость обслуживания открытой низкоуровневой обработки персистентных объектов на уровне классов доступа Java - короче говоря, это сберегат ресурсы процессора и памяти.

Oracle Lite демонстрирует успешность попытки смешения портативности Java, оригинальных средств реляционной базы данных и возможностей копирования данных, без ущерба работоспособности системы. Короче говоря, Oracle Lite 3.0 рассматривается как репозиторий объектов Java (подобно концепции PSE Pro производства Object Design). Другими словами, Oracle Lite нацелен на работу с небольшими мобильными приложениями типа Network Computer (NC).

Использование Java в базе данных Oracle мотивируется обязательством компании перед NC. Так, использование Oracle Lite в NC (возможно в качестве части операционной системы NC (NCOS)) - это признание того, что даже сетевые компьютеры нуждаются в некотором локальном хранилище и в управляющем им менеджере базы данных. В этом нет ничего страшного, поскольку некоторые формы ограниченного и защищенного локального хранилища не представляют никакой угрозы портативности и защищенности кода Java. Без сомнений, Oracle хотел бы видеть свой сервер Oracle Lite встроенным в браузер Web. Поскольку он уже поставляется со средством разработки от Netscape, проблем с этой компанией не будет. Однако, Microsoft, вероятно, не будет гореть желанием поддержать эту идею.

Поскольку Sybase Adaptive Server Anywhere (бывший SQL Anywhere, а еще раньше — Watcom SQL Anywhere) долгое время являлся лидером мобильных и встраиваемых систем баз данных, Sybase играет некоторую роль в поддержке использования Java. Новая версия 6.0, которая должна появиться примерно когда вы читаете эту статью, была названа Adaptive Server Anywhere, несмотря на то, что этот продукт никак нельзя назвать новым в флагманском продукте компании Adaptive Server Enterprise.

Целью Sybase является обеспечение разработчиков языком, который может использоваться на всех уровнях. Adaptive Server Anywhere является первым продуктом, использующим “общий процессор языка”, транслирующий Java и SQL Transact (патентованный язык баз данных Sybase) в хранимую процедуру на машинном языке. Кроме того, была добавлена возможность хранить объекты Java в колонках реляционной базы данных Adaptive Server Anywhere. Каждая колонка представляет собой тип данных с таким же именем, как и у хранимого класса Java.

Поскольку продукты типа Adaptive Server Anywhere не используют Java-классы и JVM (Java Virtual Machine), имеющиеся в браузере Web, очень важным моментом, препятствующим их использованию на рынке мобильного программирования, является размер. Разумеется, до того, как такие продукты будут распространены в Web или в сверхпортативных компьютерах, использующих Microsoft Windows CE, достаточно сложно сказать, является их размер неприемлемо большим, или нет. Например, с точки зрения Web все, что имеет размер свыше 500 кб, уже слишком велико для ненаблюдаемого переноса по модему. С другой стороны, все, что помещается в доступную ROM сверхпортативного или PDA-компьютера, приемлемо.

Ожидавшийся, но опоздавший на вечеринку Informix, в марте объявил свою стратегию, состоящую из четырех пунктов. Эта стратегия преследует цель использования Java - в особенности JavaBeans - в флагманском продукте компании - Dynamic Server.

• Informix Dynamic Server должен быть расширен и работать как контейнер, содержащий Enterprise JavaBeans, которые могут из этого контейнера вызываться.
• Dynamic Server должен поддерживать Java Virtual Machine, так что разработчики смогут писать модули DataBlade на Java.
• Informix предоставит поддержку интерфейса Java Virtual Table. Это позволит интегрировать и получать доступ к дополнительным объектам или компонентам Java.
• Informix учтет все отраслевые стандарты Java — JDBC 2.0 и SQLJ.

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

Broadbase Inc. еще не протрубил в свой Java-горн, в отличие от других компаний, возможно потому, что эта компания имеет другую клиентуру. Broadbase 1.2 - это программа работы с данными, имеющая доступ к Web и OLAP. Она была спроектирована для получения данных с различных источников с дальнейшим их анализом. Например, она предоставляет специализированное OLAP-средство relational cube - объект базы данных, хранящий предварительно откомпилированные множества со множеством узкоспециализированных характеристик или размерностей (таких, как район, менеджер по продажам и финансовый квартал).

На заднем плане Broadbase использует процессор реляционной базы данных и работает с данными через ODBC и, конечно, JDBC. Забавно, что Broadbase интенсивно применяет технологию Microsoft COM и поставляется с Microsoft JVM. Если вы захотите расширить или модифицировать функциональность программы, можно будет в качестве процедурного языка использовать Java. По духу это напоминает создание хранимых процедур в других продуктах.

Если у вас сложилось впечатление, что в случае с серверами баз данных Java может предложить многое, то закономерным будет вопрос — “Почему не пойти по пути написания сервера на Java?” Это примерно то, что делает JBMS 1.0 производства Cloudscape Inc.

Cloudscape JBMS подгоняет образцы, разработанные другими поставщиками реляционных СУБД под системный рынок встраиваемых программ. JBMS - это объектная/реляционная СУБД; применяя этот подход, Cloudscape пытается найти точки пересечения в мире реляционных данных. Как и другие программы, JBMS подключается к другим данным через JDBC, а в качестве языка запросов использует SQL. В отличие от остальных, JBMS на 100-процентов Pure Java и обладает модульностью, что позволяет добавлять или убирать компоненты в зависимости от нужд приложения. Конфигурирование позволяет оптимизировать атрибуты — возможна ориентация на одного пользователя, на экономное использование ресурсов (1 Мб или меньше) или на множество пользователей. Ее Java-код можно расширить модульным доступом или методами сортировки.

Следует обратить внимание, что Broadbase использует реляционную базу данных, а JBMS - объектно-реляционная система. Еще пара шагов в сторону объектно ориентации - и она не будет отличаться от СУБД, поддерживающих Java и считающихся объектно-ориентированными. Большинство поставщиков объектно-ориентированных СУБД, включая Object Store, Poet, Objectivity и Ardent Software (бывшая O2 Technology, слившаяся с Unidata), разработали стыкуемость с Java. Реализуя стандарт API Java для объектно-ориентированных баз данных, они весьма плотно работают с Object Database Management Group (ODMG).

Хотелось бы подчеркнуть, что пока ни одна из созданных объектно-ориентированных СУБД не была написана на Java. Исключением является W3apps Inc. (Www.w3apps.com), недавно выпустившая Jeevan - объектно-ориентированную СУБД, написанную на Java. Теоретически, союз Java (языка программирования) и объектно-ориентированного управления данными должен быть плодотворен. Путаницы между данными в кортежах и таблицах и тем, как они используются в свойствах и методах, быть не должно. Выражаясь терминами поставщиков объектно-ориентированных СУБД, имеет место несовпадение нулевого импеданса. Модель программирования схожа с моделью данных.

Среди приверженцев реляционных баз данных есть такие, кто считает, что Java со своим окружением не что иное, как табун троянских коней. Использование Java для триггеров и хранимых процедур более приемлемо , нежели использование патентованных языков типа Oracle PL/SQL. Наконец, на рынке преобладает именно навык программирования на Java. К сожалению (или, к счастью - в зависимости от вашего отношения к этому), использование Java подразумевает введение в традиционно процедурное окружение SQL-баз данных классов и объектов. В какой-то момент может случиться так, что люди, тяготеющие к Java, предпочтут полностью объектно-ориентированные СУБД.

Другие же могут посчитать это неразумным - они не захотят работать с триггерами и хранимыми процедурами в Java до тех пор, пока компании типа Oracle не сделают это возможным. Сам этот факт говорит о том, что эти люди не готовы повернуться лицом к объектно-ориентированным базам данных. То, что для Java (и для JavaSoft) JDBC имеет столь серьезный вес, вполне доказывает ведущую роль реляционных баз данных, причем эта ситуация изменится не скоро. Это - одна из причин, почему Oracle, Informix и IBM стремятся взаимодействовать с SQLJ - спецификацией встраивания SQL в Java. То, как вы будете манипулировать данными - при помощи Java или другого языка, никак не повлияет на саму основу структуры базы данных.

В любом случае, производители будут пытаться использовать уникальную модель распространения Java и то, что она так бурно развивается. Если внимательно поискать Java на рынке серверов баз данных, то вы скажете “Ребята, а ведь все это еще только начинает появляться!” В то же время, вы будете продолжать постоянно слышать о том, насколько предпочтительнее использование Java для приложений управления данными, приложений среднего уровня и распределенных приложений. Может быть слишком рано радоваться? Да. Те продукты, которые уже доступны, являются сырыми. Хотя, в Интернет этот этап развития проходит достаточно быстро. Пройдет не больше двух лет, прежде чем использование Java в серверах баз данных приведет к бурному появлению зрелых решений. Думается, что по мере увеличения важности распределенных объектов, одновременно будет возрастать и важность Java-ориентированных систем баз данных для создания, управления и хранения объектов. Так что поверьте нам на слово ... и продолжайте работать.

С вопросами и предложениями обращайтесь digraph@rinet.ru

Copyright © 1994-2016 ООО "К-Пресс"