B java существует класс Throwable, характеризующий все, что можно установить в качестве исключительной ситуации, или исключения (exception). Базовым типом, устанавливаемым из любого стандартного метода библиотечного клас­са Java и пользовательских методов и подпрограмм этапа выполнения, являет­ся класс java. lang. Exception.

Указанным классом реализуется интерфейс java. io. Serializable. В ObsHelper содержится несколько конструкторов, позволяющих создать несколько объек­тов ObsHelper в соответствии с конкретными потребностями.

Компонент в java строится с помощью базовых блоков. Более того, компонент Observation простой бизнес-объект — разрабатывается с применением реали­заций JDBC и SQLJ. Observation позволяет клиенту обращаться к базе данных Оrасlе8i и вводить массив наблюдений за атмосферой океана в таблицу OCEANIC_OBSERVATION_LIST. Эта таблица является частью научной схемы наблю­дений, представленной во введении.

Компонент состоит как минимум из интерфейса и класса реализации, которые, работая в совокупности, создают некий функциональный набор. В частности, Observation состоит из:

■   Интерфейса Observation

■   Класса реализации Obslmp

■   Класса ObsHelper

■   Класса ObsException

■   Класса Client

На рисисунке представлены основные строительные блоки компонента в java. Прежде всего — описания классов ObsHelper и ObsException.

■    Разбиение сложных прикладных программ на программные ком­поненты Следовательно, различные задачи можно распределять сра­зу среди нескольких разработчиков, получая несколько оперативных и независимых решений.

■    Упрощение модернизации и обслуживания Нередко обновление и обслуживание монолитных систем оказывается довольно дорогим и долгим. Программные приложения, моделирующие бизнес-объекты, более гибки, расширяемы, и применять их можно неоднократно.

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

■    Использование объектных оболочек при обращении к старым систе­мам Старые (унаследованные) системы — неотъемлемая часть нынеш­них. Объектные оболочки — объектно-ориентированные интерфейсы, окружающие старые системы,— позволяют последним в полной мере уча­ствовать в работе информационных систем нового поколения, делая их доступными и разрешая связь с ними. Например, web-браузеры с CORBA или клиенты CORBA могут напрямую вызывать объектные оболочки, если, конечно, оболочки созданы с помощью OMG IDL.

Для распределенных объектных вычислений существует несколько стандартов:

■ Группа управления объектами (OMG, Object Management Group) в начале 1990 г. разработала общую архитектуру посредника объект­ных запросов (CORBA, Common Object Request Broker Architecture),

в основе которой лежит абстрактная модель, называемая архитекту­рой управления объектами (ОМА, Object Management Architecture), где для организации взаимодействия между клиентскими и серверны­ми объектами и управления ими применяется посредник объектных запросов (ORB, Object Request Broker). Удаленное обращение осуще­ствляется через протокол Internet Inter-ORB (ПОР). Он дает возмож­ность писать распределенные программы взаимодействия через Ин­тернет на разных языках программирования. Объекты и интерфейсы CORBA определяются при помощи языка описания интерфейсов OMG (OMG IDL, OMG Interface Definition Language). Он позволяет взаимодействовать клиентским и серверным объектам, написанным на разных языках программирования. В число соответствий OMG IDL для языков программирования (Java, С, С++, Ada и COBOL) входят описания специфичных типов данных и интерфейсов для обращения к объектам CORBA. Объекты CORBA можно распределят!» на многие аппаратные платформы (рабочие станции UNIX, Windows NT и др.). CORBA описывается в главах 6-9.

■    Распределенная компонентная объектная модель (DCOM, Distributed Component Object Model), разработанная в Microsoft,— это компонент­ная технология распределения приложений в архитектуре Windows. Она основана на компонентной объектной модели (COM, Component Object Model), которая позволяет клиентам вызывать службы, предо­ставляемые согласующимися с СОМ компонентами (объектами СОМ). Объекты и интерфейсы СОМ определяются при помощи языка описания интерфейсов IDL (Microsoft Interface Definition Language), расширения стандарта DCE Interface Definition Language.

■    Удаленный вызов методов Java (RMI, Remote Method Invocation) от Sun JavaSoft позволяет объекту Java, функционирующему и одной вир­туальной машине Java (JVM, Java Virtual Machine), вызывать методы другого объекта Java, функционирующего в другой JVM. В RMI с этой целью используется протокол JRMP (Java Remote Method Protocol). Кстати, способ, изначально задуманный для работы только в среде Java. В июне 1999 г. Sun выпустила спецификацию RMI over IIOP (RMI-IIOP): будучи разработанной совместно Sun и IBM, она позволя­ет объектам Java взаимодействовать с объектами CORBA. Специфика­цией RMI-IIOP поддерживаются и платформы JDK начиная с 1.1.6, и Java 2.

■    Компонентная архитектура JavaBeans от Sun JavaSoft позволяет разра­ботчикам создавать клиентские компоненты, которые можно соби­рать при помощи визуальных построителей приложений (например, Oracle JDeveloper или Visual Cafe) и невизуалыгых средств Подробнее о разработке компонентов JavaBean см. в главе 11.

■    Enterprise JavaBean (EJB) — это компонентная модель, позволяющая разработчикам распределять компоненты па сервере (на прикладных серверах и серверах баз данных). В приложениях EJB удаленный вы­зов соответствует спецификации RMI, но производители не ограниче­ны транспортным протоколом RMI. Например, на сервере EJB в Огас- 1е8гв качестве транспортного протокола применяется RMI over IIOP. Серверные компоненты используются на прикладных серверах проме­жуточного программного обеспечения, где компоненты обслуживают­ся во время выполнения программы и доступны для удаленных клиен­тов. С появлением РСУБД Огас1е8г разработчики получили возможность сохранять объекты EJB и CORBA внутри базы данных. С помощью EJB разрабатываются и внедряются N-уровневые, распределенные и объект­но-ориентированные приложения Java.

Распределенные объектные системы служат фундаментом трехуровневой ар­хитектуры, в которой логические схемы представления, или первый уровень, находятся на станции клиента, бизнес-логика на среднем уровне, а база дан­ных — на третьем. Распределенная объектная технология расширяет средний уровень, позволяя обращаться не только к одному прикладному объекту, но и к нескольким. В результате рождается новая архитектура, называемая N-уpoвневой (N-tier), или многоуровневой (multi-tier). В ней возможно сосуществование множества прикладных объектов (т.е. серверов баз данных, объектов Java RMI, EJB, CORBA, DCOM и др.), причем клиентские и серверные объекты взаимодействуют посредством специального протокола удаленного вызова методов (RMI, remote method invocation). Протокол RMI используется для удаленного вызова коммуникационных методов. Например, у каждой из моде­лей CORBA, Java RMI и Microsoft DCOM он свой. У любого прикладного объ­екта есть определенный интерфейс объектной оболочки, где заявляются услуги, предоставляемые объектом и особенно важно, что связь осуществляется только через этот интерфейс.

В основе всех распределенных объектных протоколов лежит одна и та же базовая архитектура. Распределенные объектные архитектуры основаны на сетевом коммуникационном слое (уровне), состоящем из трех частей: объект­ного сервера (object server), скелета (skeleton) и изолятора (stub). Первый и вто­рой располагаются, как правило, на среднем уровне, но u Oracle8i находятся на третьем (т.е. на сервере баз данных). Изолятор размещается на машине клиента и обеспечивает межпроцессную связь клиентских и серверных объ­ектов. Для клиента он выступает в роли посредника и несет ответственность за коммуникационные запросы первого, передаваемые объектному серверу через скелет. Изолятор и скелет отвечают за то, чтобы объектный сервер (который может находиться на среднем или третьем уровне) выглядел так, будто он работает в определенном месте.

Пересылают данные из одного адресного пространства в другое изолятор и скелет с помощью двух процессов — упорядочения (marshaling) и обратного упорядочения (unmarshaling). "Во время упорядочения параметры вызова мето­да (в пространстве клиента) или возвращаемые значения (в пространстве сервера) упаковываются в стандартный формат для передачи" (См. книгу "OracleSz SQLJ Programming". Osbornc/McGraw-Hill (далее OMcGH), 1999).

Общей характеристикой современных корпоративных и правительственных сетей является их неоднородность (гетерогенность). Неоднородные системы представляют собой комбинацию множества ОС, разнесенных среди несколь­ких аппаратных (мэйнфреймы, рабочие станции, персональные компьютеры и др.) и программных компонентов. Распределение объектных вычислений — это метод построения программной инфраструктуры, объединяющей компо­ненты сети и позволяющей им взаимодействовать друг с другом.

Рассмотрим, каковы основные принципы распределенных вычислитель­ных систем и как последние связаны со специалистами по информационным технологиям, отвечающими за построение информационных систем, и систе­мами управления БД, в частности с объектно-реляционной БД Оrасlе8i  (вер­сий 8.1.5, 8.1.6 и 8.1.7), реализующей архитектуры компонентных моделей на сервере баз данных.

В основе всех архитектур распределенных вычислений лежит взаимодейст­вие компыотсрЪв. Новейшей разработкой в системах распределенных вычис­лений является распределение объектов, когда объекты (бизнес-логика и дан­ные) разносятся по неоднородной сети: независимо от того, находятся ли они в различных адресных пространствах или на разных компьютерах, объекты кажутся частями единого целого.

Термином "распределенные объектные вычисления" (distributed object computing) обозначаются те программы и приложения, которые удаленно вызывают другие программы, находящиеся в других адресных пространст­вах, а возможно, и на других компьютерах и/или в других сетях. Распреде­ленные вычисления — это основа вычислений, ставшая результа­том постепенного сближения объектно-ориентированной технологии и технологии клиент/сервер. Более того, она обеспечивает взаимодействие и возможность многократного использования распределенных объектов, что позволяет разработчикам строить системы, собирая компоненты от разных поставщиков.

■    Независимость Компонент — обобщенная единица, не зависящая от приложения.

■    Многократное использование Это многократно используемые едини­цы. По сравнению с конкретными решениями конкретных проблем компоненты более общие, что допускает неоднократное их использова­ние в самых различных контекстах.

■    Настройка Отдельные компоненты можно делать на заказ, удовлетво­ряя определенные потребности, а готовый — настроить так, чтобы он им соответствовал.

■    Компоновка Собрав несколько компонентов, можно сформировать работоспособную систему.

■    Простота модернизации и обслуживания Модернизация отдельных компонентов устраняет необходимость в объемной модернизации, обязательной в монолитных системах.

■    Прозрачность местонахождения Компоненты могут находиться в любом месте сети, на наиболее удобных для их функционирования компьютерах; это определяется функциями компонента.

■    Распределение С помощью таких стандартов распределенных вычис­лительных систем, как Enterprise JavaBeans, CORBA или Distributed Component Object Model/Component Object Model (DCOM/COM) корпорации Microsoft компоненты и программные компоненты можно распределить по всей сети предприятия.

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

быть не революционным, а эволюционным. Собирая, т.е. объединяя заранее заготовленные компоненты, разработчики могут создавать новые конструкции.

Сборные системы, состоящие из компонентов, называются программными компонентами (software components). "Программный компонент — это струк­турная единица с заранее оговоренными интерфейсами и исключительно явными контекстными зависимостями. Он может быть установлен автономно и включен в конструкцию посторонними" [European Conference on Object-Ori­ented Programming (ECOOP), 1996].

Изначально программные компоненты рассматривались но аналогии с аппаратными компонентами и микросхемами. Они совершенно самостоятель­ны, т.е. независимы от среды и приложения и при построении работоспособ­ной системы взаимодействуют друг с другом посредством методов (операций), заявленных в их интерфейсах. Подробнее о программных компонентах мы поговорим в главе 5 при построении компонентного приложения, состоящего из трех зерен Enterprise JavaBeans.

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