|
Краткое содержание
Java является действительно открытой межплатформенной средой, которая
позволяет использовать везде однажды созданные Java-приложения. Пока еще
не у всех программистов есть возможность пользоваться этой технологией:
"написать один раз, применять везде". Тем не менее, модель построения
Java-компонентов, JavaBeans, позволяет обычным людям - не
программистам во всем мире - воспользоваться этими
преимуществами, что, в конечном итоге, решает задачи
программно-компонентной технологии.
Что такое JavaBean?
По определению, JavaBean - это "любой программный
компонент многоразового использования, которым можно визуально
манипулировать в любом средстве разработки." Это простое определение,
которое, однако, не раскрывает полностью природу JavaBean. Основной
смысл данного определения содержится в словах: "... которым можно
визуально манипулировать в любом средстве разработки." Проще говоря,
любой JavaBean - это программный компонент.
Что такое программный компонент?
Индустрия ПО давно твердит о программных компонентах и о том, каким
образом они могут изменить процесс создания приложений; но часто бывает
трудно найти подходящее определение тому, что они из себя представляют.
Это повышает уровень повторного использования программных компонентов,
сдвигая акцент с уровня профессионального программиста до уровня
создателя бизнес-приложений. Запомните этот термин "создатель
бизнес-приложений". Он означает, что программные компоненты могут быть
собраны в приложения людьми, специалистами в какой-то отрасли, в
большинстве своем, непрограммистами.
Задумайтесь о высококачественной системе отдельных компонентов.
Квалифицированные инженеры-электронщики создают каждый компонент
отдельно: усилитель, проигрыватель компакт-дисков, колонки и т.д.
- из маленьких деталей (интегрированных цепей, проводов, плат и
т.п.). На передней панели усилителя имеются кнопки управления
включением, выключением, громкостью и др., а на задней -
розетки. Эти розетки используют различные типы штекеров для
соответствующих функций, что позволяет не перепутать гнезда при
подключении колонок. Предполагается, что пользователь сможет разобраться
в системе управления и в том, какой штекер куда воткнуть. Для
этого ему совсем не нужно знать, как работают электронные схемы.
Можно провести много аналогий между высококачественной системой и
идеалом компьютерного ПО, построенных из компонентов. Рассмотрим
страницу HTML, доступную по всей сети World Wide Web, которая позволяет
мне выбрать предмет из каталога и приобрести его с помощью кредитной
карточки. Данная страница должна объяснить, куда я должен ввести данные
о моей кредитной карточке, как выбрать нужный мне продукт и приобрести
его. В идеале такая страница создается специалистом по интернету, не
программистом. Издатель строит Web-страницу, включая в нее три
программных компонента: один - для введения данных о моей
"кредитке", второй - для выбора предмета и
третий - для отображения кнопки "купить" (" buy").
Издатель "связывает" эти компоненты вместе, соединяя событие "данные о
кредитной карточке" (посылаемое компонентом кредитной карточки) и
событие "выбор продукта" (посылаемое компонентом выбора) с компонентом
"купить". Теперь когда пользователь запустил детали своей кредитной
карточки, выбрал предмет и нажал кнопку "купить", на Web-сервер
посылается запрос. Конструктор страницы HTML ничего не знает о
том, как компонент кредитной карточки выверяет свои детали или как
компонент, передающий информацию, обрабатывает этот запрос; создатель
страницы HTML просто "подключает" эти куски друг к другу для достижения
желаемого конечного результата: работающую Web-страницу.
Почему модель построения Java-компонентов важна?
По моему мнению, то, что обещает Java - это настоящий рай
для программистов: созданное однажды приложение, которое работает везде.
Платформенно-независимая природа Java и ее библиотека
стандартизированных классов, наконец, делают возможным разработку одной
версии приложения и обеспечивают выполнение этого приложения на любой
совместимой с Java системе, не прибегая к рекомпиляции или добавлению
специальной логики.
Компоненты, созданные по существующим компонентным моделям, таким как
Microsoft's ActiveX и OpenDoc, не могут переноситься с платформы на
платформу. Они выявляют ряд проблем, а именно:
Компонент, написанный в C или C++ и скомпилированный так, чтобы
обеспечивать выполнение на определенной платформе, использует присущие
данной системе команды для выполнения таких основных задач, как
например, отображение данных на экране.
В результате получаются слишком большие компоненты, чтобы их можно
было использовать для создания большого количества маленьких
компонентов, таких как командные кнопки, поля ввода, текстовые метки и
т.д. Чтобы создать любой из этих компонентов, разработчик должен
написать множество методов.
Даже использование специальных сред разработки (frameworks) не
упрощает задачу. Существующие компоненты часто являются уже законченными
приложениями: электронные таблицы, графические редакторы, текстовые
процессоры и т.д.
Платформенно-зависимый характер существующих компонентов не дает
возможности их широкого применения, что делает разработку компонентов
небольшими компаниями непривлекательной. Крупные разработчики приложений
инвестируют много денежных средств в компоненты для определенного набора
платформ. Но этот набор, как правило, не велик, и эти различные
платформы не имеют общей модели построения компонентов. Компонент
ActiveX доступен только на платформах Microsoft Windows (Даже тогда
компонент, скомпилированный на машине Intel, не может быть использован в
системе NT, не работающей на оборудовании Intel.). А компонент OpenDoc
доступен на Apple Macintosh, OS/2 и Windows; но опять же, работа
компонента на разных платформах не одинакова.
Существующие компоненты устанавливаются и регистрируются как часть
операционной системы. Если эта модель расширяется до World Wide Web,
система безопасности ПК находится под угрозой ! Компонент ActiveX и
компонент OpenDoc, загруженные динамически как часть Web-страницы, имеют
доступ к полному набору интерфейсов операционной системы; и,
соответственно, однажды установленный и зарегистрированный, компонент
может делать все, что захочет, с системой пользователя. Любой
Java-компонент, загруженный из сети, выполняется внутри специальной
оболочки Java, из которой доступ в систему тщательно контролируется
пользователем, и где, по умолчанию, он не может ничего испортить.
Цели JavaBeans
Освещая недостатки уже существующих моделей создания компонентов,
становятся очевидными некоторые цели JavaBeans. Вот некоторые
обязательные характеристики JavaBeans:
Переносимость: Написанные на Java без платформенно-зависимого
кода.
Легковесность: возможность имплементировать любой компонент, даже
такой маленький, как командную кнопку, или такой же большой, как
заполненную электронную таблицу или текстовый процессор.
Простота в создании: создание Java-компонент без реализации
бесчисленного количества методов должно быть простым как с, так
и без средств разработки. Легкость в перемещении из простого апплета в
сложный компонент.
Возможность применения в других моделях построения компонентов:
JavaBean должен уметь использоваться как первоклассный компонент
ActiveX, OpenDoc или любой другой. JavaBean может содержаться внутри
ActiveX или OpenDoc, работающих, как например, текстовый процессор, и
будет вести себя так же, как если бы он являлся "родной" частью этого
компонента. Таким образом, любой обычный JavaBean может работать в
документе текстового процессора и взаимодействовать с электронной
таблицей в том же документе. Создателю JavaBean не нужно обеспечивать
специальную логику, когда JavaBean применяется в другой среде. На
самом деле, даже сам бин может не знать, что это происходит,так как
весь процесс коммуникации и конверсии обеспечивается через "мост."
Возможность доступа к удаленным данным: любой Java-компонент может
использовать любой стандартный распределенный объект (JavaIDL или
Remote Method Invocation) или механизмы распределенных данных (JDBC)
для получения доступа к удаленным данным. Фактически, любой бин может
использовать любые возможности стандарных сред.
Версия 1.0 JavaBeans-спецификации вышла в октябре 1996, а базовая
поддерживающая ее технология продавалась как часть JDK (Java Development
Kit) (версия 1.1) и была выпущена на рынок в феврале 1997. Пакет средств
для разработки бинов (BDK) (версия 1.0), содержащий образцы бинов с
указанием исходного кода, стал доступен через интернет вскоре после
выпуска версии 1.1. Когда версия Java 1.1 станет доступна всем, будет
подготовлена база для повсеместного создания и использования
Java-компонентов.
Версия 1.0 JavaBeans-спецификации тормозит это движение в
Java-спецификациях. Для большинства областей Java-среды эти спецификации
являются просто списками дефиниций классов и методов, включенных в эти
классы. Данная спецификация бинов скорее выглядит как устав по
программированию и содержит скудное описание классов. Данное расхождение
иллюстрирует тот факт, что JavaBeans в действительности являются
результатом расширения базовой Java-среды и что при создании любого бина
привлекаются в определенном порядке все имеющиеся классы и интерфейсы.
В версии Java 1.02 единственный механизм образования, рассылки и
получения уведомления о событии осуществлялся через классы Abstract
Windowing Toolkit (AWT). Этот механизм предполагает, что объекты,
порождающие эти события, имеют некую визуальную форму на экране
компьютера; т.е. они являются "приспособлениями" интерфейса пользователя
(UI widgets). Главный механизм для осуществления коммуникации
между программными компонентами - сообщение о событии. Но
это не подходит для создания компонента из элемента пользовательского
интерфейса. Кроме того, существующий механизм передачи AWT событий не
годится для того, чтобы его можно было использовать в визуальном
средстве разработки, в котором создание связи между источниками и
обработчиками событий происходит динамично.
Новая модель управления событиями, известная как "делегирующая"
модель управления событиями, требует определения класса объекта события,
плюс интерфейса "слушателя" ("listener" interface). Внутри класса
объекта события не столько подклассы, сколько подтипы данного события,
могут доставляться к определенным в интерфейсе слушателя методам. Это
позволяет логически группировать события, одновременно обеспечивая
прямую доставку события в соответствующий метод слушателя. Кроме того,
компонент, порождающий событие, должен обеспечить методы для того, чтобы
дать возможность объектам, которые хотят получить это событие,
зарегистрироваться и разрегистрироваться самостоятельно. Только объекты,
которые зарегистрированы источником события, получают извещения.
Пример использования модели управления событиями может выглядеть
следующим образом:
Рисунок 1. Пример модели управления событиями
В этом примере мы определяем BlobEvent класс и BlobListener интерфейс
для приема событий. У нас есть класс объектов, MySource, который
порождает BlobEvent и обеспечивает методами addBlobListener и
removeBlobListener. В результате, мы имеем класс, под названием MyModel,
который хочет получить уведомления от BlobEvent и который реализует
интерфейс BlobListener.
Итак, чем же привлекательна такая новая модель? Эта новая модель
управления событиями не требует без необходимости вводить AWT объекты
подклассов и упрощает для визуального средства разработки способ
генерации классов-адаптеров, чтобы осуществлять связи event-to-method.
Программиста, который не использует визуальное средство разработки, Java
обеспечивает "внутренними" классами, чтобы упростить процесс создания
адаптеров.
С помощью данной AWT модели управления событиями метод обработчика
событий получает уже готовое событие. Если я хочу выполнить какое-нибудь
действие по событию mouseUp, каждое событие, типа mouseClick, mouseMove,
keyUp, resize и т.п., также проходит через мой обработчик событий. В
данной модели сообщения получают только те объекты, которые
зарегистрировались исключительно источником события. Даже тогда они
получают те события, к которым они проявили интерес. Фильтрование
происходит автоматически.
Сохранение
Схема сохранения дает возможность компоненту сохранять свое состояние
при каждом обновлении. С помощью данного механизма сохранения компонент
электронной таблицы может быть сохранен в файл, а при открытии
предоставить все данные, формулы и установки нетронутыми. С другой
стороны, набор компонентов, представляющих целый документ, например,
текстовые страницы с с графиками, электронными таблицами, графическими
объектами и т.п., может быть "упакован" и затем перенесен по сети и
распакован где-нибудь еще. Схема сохранения JavaBeans использует
механизм сериализации объектов среды Java 1.1, чтобы позволять
компонентам автоматически упаковываться в поток ввода/вывода и позже
снова восстанавливаться. Создателю компонента необходимо только
имплементировать интерфейс сериализации (serializable interface), чтобы
сделать так, чтобы компонент cохранялся. В качестве используемого
устойчивого потока для сохранения объектов (persistent stream) может
служить любой Java-файл, сетевая связь или, что может представить
больший интерес, поток, обеспечиваемый другой моделью построения
компонентов. Если любой JavaBean-компонент содержится внутри компонента
ActiveX или OpenDoc, этот бин обеспечивается таким потоком сохранения
(persistent stream) через соответствующий "мост" и становится частью
механизма сохранения всего компонента. Включение слов "implements
serializable" в определение классов компонента подразумевает, что авторы
создания данного компонента уже позаботились о том, чтобы компонент имел
возможность не столько создаваться и уничтожаться, сколько запоминаться
и восстанавливаться; т.е. они продумали возможность инициализации,
временных переменных и т.д.
Кастомизация
Кастомизация - одна из новых характеристик
JavaBean-компонентов. Проще говоря, создатель бина не только создает
работающий компонент, но также может, по своему усмотрению, создать
элементы пользовательского интерфейса (UI widgets) для отдельного
класса, расширяющего возможности java.awt.Component класса. Такое
приспособление затем может быть использовано при кастомизации объекта
бина. В других моделях построения компонентов среда разработки, средства
разработки - либо что бы то ни было - должны
обеспечивать логику кастомизации для тех компонентов, которые она
использует. Компонент не способен осмысленно кастомизировать сам себя.
Это может ограничивать наши возможности.
JavaBean-компонент может быть выгружен со своим собственным классом
элементов интерфейса пользователя (UI widgets), способного осмысленно
осуществлять кастомизацию. Среда разработки может позволить кастомизацию
Java-компонентов, созданных в любом другом месте. Средства разработки
берут соответствующий класс-кастомизатор и создают его объект внутри
одного из его окон; больше ничего им не нужно знать.
Интроспекция
Чтобы Java-компоненты могли повторно использоваться в среде
разработки, должен быть способ определения того, что бин может делать в
плане методов, которые он поддерживает, и типов событий, которые он
порождает и/ли слушает. В JavaBeans-спецификации это называется
интроспекцией и является дальнейшим развитием основных механизмов
отображения, обеспеченных версией Java 1.1.
Механизмы отображения позволяют сделать запросы во время исполнения
таким образом, чтобы можно было найти класс объекта и детали его
открытых методов и переменных. Механизм интроспекции бина расширяет его
возможности путем выбора определенных моделей проектирования или, как
другой вариант, путем определения точной спецификации возможностей
своего компонента. Создатель компонента может точно определить
возможности компонента при создании соответствующего BeanInfo класса.
Использование BeanInfo класса позволяет создателю бина отображать только
определенный набор открытых методов и переменных этого бина.
Более того, мы можем прибегнуть к помощи BeanInfo класса, когда
повторно используем часть существующего Java-кода как компонент.
Существующая имплементация может не следовать моделям проектирования
бина не смотря на то, что она имеет все необходимые для этого
возможности. И, в этом случае, механизм интроспекции по умолчанию не
может правильно определить внешний интерфейс бина. Программист может
создать BeanInfo класс, детально описывая названия методов для получения
и установки свойств и т.п.; и таким образом, не принимать во внимание
схему интроспекции по умолчанию.
Упаковка
JavaBean-компоненты обычно упаковываются как JAR- файлы. JAR-формат
позволяет упаковать компонент как единое целое вместе с поддерживающими
его классами, такими как редакторы кастомизации, BeanInfo и ресурсы, как
например, графические иконки бина. Среда разработки должна понимать
JAR-формат и использовать информацию его файла-манифеста, чтобы
идентифицировать бины, содержащиеся в JAR.
JAR, который содержит JavaBean-компонент, также может включать версию
каждого сериализованного компонента. Если такой сохраненный объект
(persistent instance) существует, тогда нет необходимости создавать
новый объект класса при создании пользователем компонента данного типа.
Это позволяет производителю поставлять уже готовую к выполнению или
кастомизированную версию компонента.
Например: я системный интегратор, обеспечиваю клиента набором
компонентов, которые он может применять при построении приложений. Как
интегратор, я располагаю набором стандартных компонентов (но все они
имеют установку по умолчанию) только с моим логотипом и цветовой
схемой. Когда я обеспечиваю своего клиента этими компонентами, я создаю
кастомизированные версии, в которых используется стандартная цветовая
схема компании клиента, включая и их логотип (расположенный рядом с
моим, конечно). Чтобы это сделать, я просто добавляю версию каждого
сериализованного компонента в JAR-файл стандартного компонента. Я
отправляю клиенту JAR-файлы, дополнительно включив и сериализованную
версию компонента. Теперь когда среда разработки клиента создает новый
компонент, одновременно строя приложение, она использует
сериализованную, т.е. кастомизированную версию, а не создает объект
класса. Как результат, все компоненты выглядят и выполняются, как того
желает клиент.
Заключение
До настоящего момента индустрии создания компонентов не хватало
платформенно-независимой архитектуры. Существующие архитектуры связаны с
конкретными платформами, которые требуют платформенно-зависимые двоичные
коды. Несмотря на то что поставка компонентов конечному пользователю
растет, зависимость от платформ и несогласованное
взаимодействие компонентов, созданных различными производителями,
являются существенными недостатками.
Присущая Java независимая от платформы среда выполнения в сочетании с
легковесной и простой моделью построения компонентов, JavaBeans,
обеспечивает потенциал для значительного увеличения количества удобных в
использовании компонентов. Теперь разработчик компонентов может
действительно создать такой компонент, который можно виртуально
применять везде. К тому же, встроенные схемы надежности и безопасности
Java-среды значительно уменьшают возможность несанкционированного
взаимодействия компонентов различных ппроизводителей, а созданная
на базе компонентов вычислительная среда может использоваться сетью.
Некоторые уникальные
характеристики JavaBeans (кастомизация, интроспекция и др.) открывают
закрытые на данный момент среды разработки. Это в сочетании с
возможностями динамической загрузки Java-среды устраняет необходимость
установки каждого компонента в среду разработки и способствует
динамическому расширению спектра имеющихся ресурсов.
|
