АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем

• Название: Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
• Дата: 03.06.2022
• Размер: 4.65 Mb.
• Имя файла: АРИС Текст 2.docx
• Тип: Документы; #568218
• страница: 21 из 30

Брокер объектных запросов - Object Request Broker (ORB). Брокер объектных запросов представляет собой объектную шину, которая позволяет объектам прозрачно генерировать запросы и получать ответы от локальных или удаленных объектов, причем клиент ничего не знает о механизмах, которые используются для создания и сохранения состояния Поскольку CORBA – это только спецификация, которая может быть реализована разными поставщиками, то начиная с CORBA 2.0 определяется взаимодействие (interoperability) ORB разных производителей

CORBA ORB позволяет объектам обнаруживать друг друга во время выполнения (на лету) и вызывать сервисы друг друга, т.е. реализует типовой спектр сервисов распределенного промежуточного программного обеспечения, однако ORB намного более сложен, чем, например, вызовы удаленных процедур, в частности:

• 
  поддерживает как статические, так и динамические вызовы методов;
  
• 
  отделяет интерфейс от его реализации;
  
• 
  является самоописываемой системой.
  
• 
  прозрачность относительно места положения объектов.
  

Все ORB позволяют реализовывать как статические, так и динамические вызовы методов.

Статические и динамические вызовы методов. CORBA ORB позволяет статически определять вызовы ваших методов во время компиляции или находить их динамически во время выполнения.

К достоинствам статического вызова методом можно отнести наличие строгого контроля типов на стадии компиляции и высокая скорость работы, а динамического - максимальная гибкость при отложенном (на этапе выполнения) связывании. (Следует отметить, что большинство других видов middleware поддерживают только статическое связывание.)

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

Самоописываемая система. CORBA предоставляет метаданные на этапе выполнения для описания каждого серверного интерфейса, известного системе. Каждый CORBA ORB должен поддерживать Репозитарий Интерфейсов (Interface Repository), который содержит текущую информацию, описывающую предоставляемые сервером функции и их параметры. Клиенты используют метаданные, чтобы определить, каким образом вызывать сервисы во время выполнения. Метаданные также помогают инструментальным средствам создавать код «на лету». Такие метаданные генерируются автоматически либо прекомпиляторами языка IDL, либо такими компиляторами, которые знают, как генерировать IDL непосредственно из объектно-ориентированного языка.

Прозрачность относительно места положения объектов. ORB может поддерживать взаимодействие между объектами, расположенными в одном процессе, на одном хосте и на разных хостах одной локальной сети. Если требуется организовать взаимодействия с другими объектами, находящимися, например в Internet, то используются сервисы протокола IIOP (Internet Inter-ORB Protocol — Internet-протокола взаимодействия ORB), причем это делается прозрачно для пользователя.

ORB может выступать посредником при взаимодействии между "мелко-зернистыми" объектами, по уровню сложности соответствующих например классам C++, так и для "крупнозернистых" объектов, в качестве которых могут выступать, например бизнес-объекты.



Рис. 10.3. Структура ORB

Структура ORB показана на рис. 10.3.

ORB позволяет устанавливать клиент-серверные отношения между объектами в распределенной компьютерной среде, при этом один и тот же объект может выступать как в качестве клиента, так и в качестве сервера.

Для обращения к серверу клиент может использовать либо статический, либо динамический вызов.

При реализации статического вызова используются стабы (Stub). определяются посредством IDL, cтабы клиента и сервера генерируются компилятором IDL. Клиент должен иметь стаб для каждого интерфейса, который содержит, в частности, код маршалинга. Для обращения к удаленному объекту клинт достаточно просто вызвать метод. С точки зрения клиента стабы — это локальный заместитель (proxy) для удаленного объекта

При реализации динамических вызовов, т.е. вызовов, не использующие предварительно скомпилированные заглушки, клиент использует интерфейс динамического вызова (ИДВ) (Dynamic Invocation Interface), который позволяет обнаруживать методы, которые необходимо вызвать, во время выполнения. CORBA предлагает стандартный API для поиска метаданных, определяющих серверный интерфейс, генерации параметров, удаленного вызова и получения результатов.

Указанные метаданные хранятся в репозитария интерфейсов (Interface Repository), который представляет собой распределенную базу данных, которая содержит в машинном формате версии определенных на IDL интерфейсов.

API Репозитария Интерфейсов (Interface Repository API) позволяет получать доступ описаниям интерфейсов зарегистрированных компонентов, поддерживаемых ими методов и их параметров. В CORBA такие описания называют сигнатурой метода (method signature).

Интерфейс ORB предлагает ряд полезных сервисов, в частности, API для преобразования ссылки на объект в строку и обратно, что может быть полезно в случае, если необходимо сохранять или пересылать ссылки.

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

Сравнивая статические, так и динамические вызовы, следует отметить, статические вызовы намного проще в программировании, они быстрее работают и самодокументируемы. Динамические вызовы предоставляют максимальную гибкость, но они сложнее в программировании, но незаменимы в случае, когда на стороне клиента невозможно установить заглушку.

Серверная часть не может определить разницу между статическим и динамическим вызовом, поскольку оба они имеют одинаковую семантику сообщения. В обоих случаях ORB находит объектный адаптер сервера, передает ему параметры, а затем передает управление коду объекта с помощью заглушки (стаба), который в CORBA называется скелетоном (skeleton) сервера.

На стороне сервера размещаются статические скелетоны, динамические скелетоны и адаптеры объектов.

Статические скелетоны предоставляют статические интерфейсы каждому из реализуемых сервисов. Эти стабы создаются компилятором IDL и определены для каждого класса объектов.

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

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

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

CORBA предлагает два типа адаптеров объектов: базовый адаптер объектов (Basic Object Adapter, BOA) и переносимый адаптер объектов (Portable Object Adapter, POA).

Сервисы CORBA. В качестве базовых сервисов в рамках CORBA используется пятнадцать сервисов:

• 
  сервис Именования (Naming);
  
• 
  сервис Жизненного Цикла (Life Cycle);
  
• 
  сервис Событий (Event Service);
  
• 
  сервис Долговременного Хранения (Persistence Service);
  
• 
  сервис Контроля Совместного Доступа (Concurrency Control Service);
  
• 
  сервис Транзакций (Transaction Service);
  
• 
  сервис Отношений (Relationship Service);
  
• 
  сервис Внешнего Представления (Externalization Service);
  
• 
  сервис Запросов (Query Service);
  
• 
  сервис Лицензирования (Licensing Service);
  
• 
  сервис Свойств (Properties Service);
  
• 
  сервис Времени (Time Service);
  
• 
  сервис Безопасности (Security Service);
  
• 
  сервис Коммерции (trading Service);
  
• 
  сервис Контейнеров (Collection Service).
  

Объектные сервисы являются базовыми строительными блоками для создания распределенной объектной инфраструктуры. Они представляют собой следующий этап в последовательности шагов, направленных на достижение главной цели — создания распределенных компонентов, или, как их называет OMG, бизнес-объекта (business objects).

Базовые сервисы CORBA являются инфраструктурными сервисами независимы не связаны ни с одним предметным доменом.

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

Сервис именования отображает CORBA имена в объектные ссылки. Контекст имен (naming context) представляет собой пространство имен (namespace), в котором имена объектов уникальны. Каждый объект имеет уникальный ссылочный идентификатор (reference ID).

Сервис Именования был разработан на основе существующих служб имен и каталогов.

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

Сервис Событий (Event Service) позволяет компонентам, находящимся на шине, реагировать на события, происходящие в системе. Объекты имеют возможность регистрировать интерес к определенным системным событиям или отменять такую регистрацию.

Сервис Долговременного Хранения (Persistence Service) – это служба, позволяющая создавать хранилища компонентов в различных средах, включающих плоские файлы и реляционные базы данных.

Сервис Контроля Совместного Доступа (Concurrency Control Service) предоставляет собой механизм, который позволяет выполнять блокировки от имени транзакций и потоков выполнения

Сервис Транзакций (Transaction Service) позволяет организовывать двухфазное завершение (two-phase commit) транзакций для компонентов, при этом имеется возможность работать не только с простыми (flat), но и вложенные (nested) транзакции.

Сервис Отношений (Relationship Service) позволяет создавать динамические ассоциаций между компонентами, непосредственно не связанными друг с другом.

Данный сервис используется, преимущественно для обеспечения целостности.

Сервис Внешнего Представления (Externalization Service) обеспечивает стандартный способ для передачи данных компоненту и обратно, а также для пересылки самих компонентов по сети. По сути – это сервис сериализации.

Сервис Запросов (Query Service) позволяет выполнять запросы для объектов, в частности, находить объекты по их свойствам. В основе Сервиса Запросов лежит SQL3 и язык объектных запросов (Object Query Language).

Сервис Лицензирования (Licensing Service) позволяет отслеживать использование компонентов с целью получения платы.

Сервис Свойств (Properties Service) предоставляет доступ к свойствам компонентов, позволяет, в частности, читать значения свойств, изменять значения свойств, изменять состав свойств.

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

Сервис Безопасности (Security Service) позволяет поддерживать инфраструктуру для обеспечения безопасности системы распределенных объектов, включая такие механизмы как аутентификацию, списки контроля доступа и конфиденциальность и, кроме того, отвечает за делегирование прав доступа к объектам.

Сервис Коммерции или Трейдер Сервис (Trader Service) – это сервис «Желтых страниц» для объектов; позволяющий опубликовывать предлагаемые сервисы и находить их.

Сервис Контейнеров (Collection Service) позволяет создавать контейнеры, в которые можно помещать компоненты и формировать из них контейнеры.

Средства CORBA (Common Facilities) делятся на вертикальные и горизонтальные.

Горизонтальные универсальные средства определяют интерфейсы, не зависящие от предметной области.

Горизонтальные средства включают:

• 
  средства пользовательского интерфейса (USER Interface), которые включают инструменты для разработки интерфейса, средства для автоматизации разработки интерфейса, спецификации на рабочее пространство пользователя и т.д.;
  
• 
  средства управления информацией (Information management), которые предоставляют операции, с помощью которых можно моделировать, описывать, сохранять, выбирать, перемещать информацию и обмениваться ею;
  
• 
  средства управления системой, включающие множество утилит, реализующих функции системного администрирования, то есть определяют интерфейсы основных операций, обеспечивающих управление, мониторинг, безопасность, конфигурирование и т.д.;
  
• 
  средства управления задачами, включающие средства управления потоками работ (workflow facility), средства программных агентов (agent facility), средства управления правилами (rule management facility), средства автоматизации (automation facility).
  

Вертикальные средства предназначены для поддержки конкретных областей рынка: финансовой деятельности, промышленного производства, медицины и т.д. [141].

10.3. Технология Enterprise JavaBeans

Технология EnterpriseJavaBeans (EJB) представляет собой высокоуровневый подход к построению распределённых приложений масштаба предприятия. EJB - это модель серверных компонентов (servercomponentmodel) для Java.

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

Краткая история. Фирма Sun Microsystems Inc. анонсировала технологию EJB в 1996 году, а в 1998 года была представлена первая реализация (версия 1.0). На момент написания книги последней была версия EJB 3.0, которая появилась в 2006 году.

Версии. EJB 1.0. Это начальная версия, в рамках которой поддерживались stateful и stateless компонент, с которыми можно было работать через удаленный интерфейс. В качестве желательной опции рассматривались компоненты, имеющие состояния.

EJB 1.1. В данном релизе в качестве обязательных появились компоненты с состоянием и XML дескриптор (deployment descriptor).

EJB 2.0. В данном релизе в дополнение к удаленному интерфейсу появился локальный интерфейс, который могли использовать компоненты, работающие в том же контейнере. Появился новый тип компонентов – компоненты, управляемые сообщениями the message-driven bean (MDB), которые могли принимать асинхронные сообщения. Для компонентов с сохранением была определена возможность сохранения состояния средствами контейнера. Появился язык Enterprise JavaBeans Query Language

(EJB QL), похожий по структуре на SQL, и предназначенный для поиска компонентов.

EJB 2.1. В рамках данного релиза появилась поддержка работы с Web-сервисами, расширились возможности EJB QL и в дескрипторе развертывания вместо DTD стала использоваться XML schema.

Можно заметить, что основные различия между версиями состоит в наращивании возможностей.

EJB 3. Данный релиз радикально отличается от предшествующих и определяет фактически новую компонентную модель. Основное отличие состоит в том, что пользователь не должен ничего знать о домашнем интерфейсе (Home Interface). В рамках данной спецификации используется идея POJO (Plain Old Java Objects) .Идея состоит в том, что программист пишет только ту часть кода, которая реализует бизнес-логику. Для того, чтобы определить каким именно способом реализуется бизнес код, используется механизм аннотаций. Например, если требуется определить интерфейс как локальный, то достаточно описать интерфейс обычным способом и вставить строку аннотацию @Local. Механизм аннотаций позволяет очень существенно упростить процесс разработки.

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

Использование EJB позволяет упростить процесс разработки КИС за счет того, что многие функции реализуются контейнерами. Кроме того, EJB можно использовать многократно, причем для повторного использования не требуется перекомпиляция всего проекта.



Рис. 10.4. Архитектурная модель EJB

EJB компоненты хорошо сопрягаются с Web-сервисами и с CORBA.

Архитектурная модель EJB включает в себя следующие элементы (рис. 10.4):

• 
  JEE контейнер;
  
• 
  EJB контейнер;
  
• 
  Web- контейнер;
  
• 
  клиент;
  
• 
  база данных (БД).
  

JEE контейнер представляет собой EJB- совместимый сервер приложений, внутри которого имеются EJB контейнер и Web- контейнер. EJB-компоненты функционируют внутри EJB контейнера, а сервлеты и JSP – внутри Web- контейнера. БД используется для хранения состояния EJB-компонентов. Для взаимодействия с контейнером EJB-компонент используют Home-интерфейс, а для взаимодействия с клиентом – Remote- интерфейс.

Кроме того, в процессе функционирования EJB-компоненты пользуются такими сервисами как JNDI, JTS, систем безопасности и т.п.

Рассмотрим основные компоненты архитектуры EJB.

JEE сервер. JEE совместимый сервер приложений обеспечивает следующие основные сервисы:

• 
  HTTP-сервис;
  
• 
  сервисы безопасности;
  
• 
  Java Naming and Directory Interface (JND) – сервисы.
  

EJB-контейнер реализует следующие сервисы:

• 
  управление жизненным циклом компонента;
  
• 
  управление транзакциями;
  
• 
  управление персистностью.
  

Рис. 10.5. Структура EJB-контейнера
EJB-контейнер поддерживает интерфейс для EJB-компонентов. Клиенты никогда не обращаются напрямую к EJB-компонентам. Все обращения идут к контейнеру, который выполняет функции посредника. На рис. 10.5 показана структура EJB-контейнера. Когда компоненты ходят обратиться к внешним компонентам, то используется информация, содержащаяся в контексте. EJB-контейнер реализует такие функции как создание и уничтожение EJB-компонентов.

EJB-компоненты образуют распределенную компонентную систему. Приложения и другие компоненты обычно могут обращаться к EJB-компоненту через удаленный интерфейс. Если вызывающий и вызываемый компоненты находятся в одном контейнере, то используется локальный интерфейс. Для того, чтобы поместить EJB-компонент в контейнер, необходимо отредактировать дескриптор размещения – (Deployment Descriptor, DD), который представляет собой XML –документ.

Компонентная модель EJB 2.Х. Каждый EJB-компонент имеет бизнес-интерфейс, через который клиент может обратиться к данному компоненту, при этом клиенту могут быть неизвестны подробности, касающиеся, в частности, места нахождения компонента. Этот интерфейс называют удаленным (remote interface). Конкретный экземпляр EJB-компонента управляется контейнером через домашний интерфейс (home interface). Каждый EJB-компонент должен поддерживать как удаленный, так и домашний интерфейс.



Рис. 10.6. Структура EJB-компонента

Конфигурирование EJB-компонента осуществляется посредством редактирования конфигурационного файла. Структура EJB-компонента и процесс взаимодействия клиента и EJB-компонента показан на рис. 10.6.

EJB класс реализует эти два интерфейса. Взаимодействие осуществляется следующим образом. Клиент обращается к компоненту по имени (Lookup), которое используется для получения объектной ссылки (Object Reference, OR) через JNDI сервис. При обращении к контейнеру (Create) он создает экземпляр EJB-компонента и передает ему параметры вызова. Очевидно, что для того, чтобы можно было получать ссылки, компоненты должны быть предварительно зарегистрированы с помощью JNDI. Затем вызывается требуемый метод (Invoke).

EJB-компонент представляет собой программный компонент, который может быть повторно использован без перекомпиляции в разных приложениях. Для использования EJB-компонента достаточно поместить его в соответствующий каталог и выполнить настройки конфигурационного файла, который называют Deployment Descriptor (DD). DD представляет собой XML файл.

Компонентная модель EJB определяет три основных типа компонентов:

• 
  сеансовые компоненты (Session Beans);
  
• 
  компоненты-сущности (Entity Beans);
  
• 
  компоненты, ориентированные на сообщения (Message Driven Beans).
  

В свою очередь, сеансовые компоненты делятся на две группы:

• 
  сеансовые компоненты без состояния (Stateless Session Beans);
  
• 
  сеансовые компоненты с состоянием (Stateful Session Beans).
  

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

Компоненты данного типа можно реализовать в виде Web-сервисов.

Сеансовые компоненты с состоянием помнят свое состояние только в пределах сеанса.

Время жизни таких компонентов соответствует одному сеансу, продолжительность которого может составлять от нескольких секунд до нескольких часов и даже дней.

Типичным примером использования Сеансовых компонентов с состоянием Интернет-магазин. EJB-компонент может описывать, например, описывает содержимое корзины покупателя. Тогда сеансом будет считаться время с момента регистрации пользователя на сайте магазина до момента закрытия пользователем браузера или перехода к другому сайту.

Компоненты-сущности, напротив, способны поддерживать свое состояние. Их состояние сохраняется в реляционной базе данных. Каждому компоненту обычно ставится в соответствие строка базы данных. В рамках компонентной модели EJB 2.Х выделяется два варианта управления состоянием компонента: ручное сохранение (Bean Managed Persistence, BMP) и автоматическое сохранение (Container Managed Persistence, CMP).

В первом случае ответственность за сохранение состояние возлагается на компонент, т.е. на программиста. Во втором случае сохранение и восстановление состояние возлагается на контейнер. Информацию, необходимую для работы с БД контейнер берет из дескриптора размещения (Deployment Descriptor, DD), который представляет собой XML файл.

При работе с компонентами-сущностями можно использовать EJB QL, который позволяет находить компоненты по первичному ключу или значениям отдельных полей.

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

Жизненный цикл и роли при работе с EJB. Как для всякой компонентной системы для EJB выделение типовых ролей при разработке и сопровождении приложений, использующих EJB.

• 
  применительно к EJBвыделяются следующие роли:
  
• 
  провайдер сервера EJB;
  
• 
  провайдер контейнера EJB;
  
• 
  разработчик EJB;
  
• 
  специалист по внедрению/установке EJB;
  
• 
  разработчик приложения.
  

Провайдер сервера EJB – это производитель EJB-совместимого сервера приложений.

Производитель сервера EJB может также выступать в качестве производителя контейнера EJB.

Провайдер контейнера EJB - это производитель EJB-контейнера. Производитель сервера EJB обычно выступает в качестве производителя контейнера EJB. Как правило, это крупные фирмы или организации, такие как IBM или Oracle.

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

Специалист по внедрению/установке EJBответственен за определение EJB, всех поддерживающих классов и их правильную инсталляцию на сервере EJB.

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

Спецификация EJB называет разработчика приложения ассемблером приложения.

Модель размещения EJB-компонента. После того как разработка кода клиента и сервера завершена, выполняется их компилирование в файлы классов. EJB-компонент упаковывается в .jar, который, в свою очередь, вместе с другими Web-компонентами (.war), DD XML файлы и коды клиентской части (.jar) упаковываются в .ear файлы.

DD – это файл размещения в XML формате. Этот файл создается обычно автоматически. Ниже приведен фрагмент DD файла:








accountBean

accounthome

account

Account


Container

Integer


...

id

...

name







...



...




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

• 
  чрезмерно тяжеловесная модель программирования, требующая работы с несколькими интерфейсами;
  
• 
  необходимость непосредственного взаимодействовать с Java Naming Directory Interface (JNDI);
  
• 
  необходимость работать с непомерно сложным XML DD.
  

Эти недостатки устранены в EJB3.0, где используется только один бизнес-интерфейс вместо home и remote интерфейсов, минимизируется использование DD за счет использования аннотаций. Кроме того, используется новый механизм для сохранения состояния для компонентов-сущностей (Entity Beans).

Одной из новых черт EJB 3 является использование JavaPersistenceAPI (JPA) для реализации сохранения состояния.

Сохранения состояния (Персистенс) – это способность автоматически сохранять состояние Java объектов в реляционных базах данных.

JPA – это самостоятельная технология, которая обеспечивает объектно-реляционное отображение JAVA объектов и предоставляющая API для сохранения, получения и управления такими объектами. Собственно JPA – это спецификация, которая представляет собой часть EJB3 спецификации. Наиболее известными реализациями JPA являются Hibernate, Oracle TopLink, Apache OpenJPA.

JPA состоит из трех элементов:

• 
  API – интерфейсы в пакете javax.persistance, представляющий собой набор интерфейсов;
  
• 
  JPQL – объектный язык запросов, похожий на SQL, но запросы выполняются к объектам;
  
• 
  Metadata – аннотации над объектами, которые представляют собой набор аннотаций, которыми описывают объектно-реляционные отображения. Метаданные можно описывать либо с помощью XML файлов, либо с помощью аннотаций.
  

Аннотирование является одной из ключевых особенностей программирования в технологии EJB 3.0. Эта возможность позволяет разработчикам аннотировать программные элементы непосредственно в исходных текстах на языке Java с целью управлять поведением или развертыванием компонентов.

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

Ниже приведен пример использования механизма аннотаций. Интерфейс описывается как обычный Java интерфейс (Plain Old Java Interface, POJI). Класс компонента представляет собой обычный Java объект (Plain Old Java Object, POJO). Строка @Stateless представляет собой аннотацию, которая указывает на то, данный объект должен быть реализован как EJB-компонент без сохранения состояния. Для того, исполнить этот компонент, его надо поместить в EJB-контейнер.
package ejb3component.example;

public interface Hello {

public void Hello(String name);

}

package ejb3component.example;

import javax.ejb.Stateless;

@Stateless

public class HelloBean implements Hello {

public void Hello(String name) {

System.out.println("Hello " + name);

}

}

Lis

tНа данном примере достаточно хорошо просматривается идея POJO, которая состоит в том, пользователь пишет только код, который реализует требуемую функциональность, а способ реализации указывает в аннотациях [142].
10.4. Компонентная модель .NET

.NETFramework — программная платформа компании Microsoft, предназначенная как для создания обычных программ и веб-приложений. .NET является патентованной технологией.

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

Основными составными частями .NET Framework являются инвариантная к языку программирования среда исполнения (common language runtime, CLR) и библиотека классов Framework (framework class library, FCL). CLR – это некоторая обертка для API ОС, которая служит средой для исполнения управляемых приложений (managed applications). FCL предоставляет объектно-ориентированный API, к которому обращаются управляемые приложения.

При работе с управляемыми приложениями программист теряет возможность работать с Windows API, MFC, ATL, COM и других знакомых инструментов и технологий и должен работать с FCL.

Если программист не хочет отказываться от «старых» технологий, то ему предоставляется возможность создавать приложения, основанные на использовании неуправляемого кода, который исполняется без использования CLR. Совмещение в рамках одного приложения управляемого и неуправляемого кода возможно, но не приветствуется разработчиками платформы.

Инвариантная к языку программирования достигается за счет того, что среда разработки создаёт байт-код, который интерпретируется виртуальной машиной. Встроенные (поставляются вместе с .NET Framework). В качестве основных языков, поддерживаемых платформой .NET, выступают: C#, VB.NET, JScript .NET, C++/CLI, IronPython, IronRuby и F# (функциональный язык общего назначения).

В качестве входного языка виртуальной машины в .NET используется Common Intermediate Language (CIL), (В более ранних версиях он назывался Microsoft Intermediate Language (MSIL)).

Применение байт-кода позволяет получить кроссплатформенность на уровне скомпилированного проекта, который называют сборкой. Функцию преобразования сборки в исполняемый код целевого процессора реализует JIT-компилятор (just in time), который выполняет компиляцию «на лету».

Кроме того, имеется утилита, которая компилирует сборку в родной (native) код для выбранной платформы.

Данный подход идентичен используемому в Java виртуальной машине.

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

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

Microsoft начала разрабатывать .NET Framework в конце 1990-х годов, и первая версия .NET 1.0 была выпущена в начале 2002 года.

Рис. 10.7. Стек технологий .NET

На момент написания данной книги основной являлась версия 4.0, которая поддерживается средой разработки Microsoft Visual Studio 2010 [143].

Практически каждая новая версия включала в себя новые технологии. Стек технологий .NET показан на рис. 10.7.

Назначение Среды выполнения и Базовой библиотеки классов описано выше.

Система построения клиентских приложений (Windows Presentation Foundation, WPF) предназначена создания как автономных, так и запускаемых в браузере приложений.

WPF представляет собой векторную система визуализации и широко использует язык XAML (Extensible Application Markup Language), представляющий собой XML, в котором реализованы классы .NET Framework. Кроме того, используются такие элементы как элементы управления, привязку данных, макеты, двухмерную и трехмерную графику, анимацию, стили, шаблоны, документы, текст, мультимедиа и оформление.

Основой WPF является DirectX, что позволяет использовать аппаратные ускорители.

Система обмена данными между приложениями (Windows Communication Foundation, WCF) представляет собой программный фреймворк, используемый для обмена данными между приложениями и входящий в состав .NET Framework.

WCF позволяет комбинировать функциональность различных технологий .NET таких как ASP.NET, Web Services, .NET Remoting, .NET Enterprise Services и System.Messaging для создания распределённых приложений

Система управления рабочими процессами (Windows Workflow Foundation, WF) - это технология для определения, выполнения и управления рабочими процессами.

WF использует визуальное программирование и в ее основе лежит декларативная модель программирования.

Использование WF предлагает три способа описания:

- последовательный процесс (Sequential Workflow);

- описание процесса в терминах конечный автомат;

- описание процесса с помощью правил.

Технология единого входа (Windows CardSpace, WCS) — это система идентификации пользователей при работе с разными ресурсами без необходимости повторного ввода имен и паролей.

Данная технология является собственностью Microsoft, что затрудняет ее использование при работе с сторонними приложениями.

Windows CardSpace — патентованная технология единого входа от Microsoft. WCS — это способ простой и безопасной идентификации пользователей при перемещении между ресурсами Интернета без необходимости повторного ввода имен и паролей.

Модель доступа к данным (ADO.NET (ActiveX Data Objects .NET))- интерфейс программирования приложений для доступа к данным, основанный на технологии компонентов ActiveX., позволяющий представлять данные из разнообразных источников, таких как реляционных баз данных, текстовых файлов и т. д. в объектно-ориентированном виде.

Язык интегрированных запросов (LanguageIntegratedQuery,LINQ) — Позволяет поддерживать механизм запросов для коллекций объектов в памяти, реляционных баз данных и данных в формате XML, обладает расширяемой архитектурой, которая позволяет сторонним разработчикам реализовать доступ к их хранилищам данных через механизм LINQ.

Параллельные расширения (Microsoft Parallel Extensions for .Net) включает два компонента:

- библиотеку параллельных задач (Task Parallel Library, TPL);

- язык параллельных интегрированных запросов (Parallel Language-Integrated Query, PLINQ).

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

Библиотека параллельных задач. В качестве базового понятия используется понятие задача (Task). Задача – это фрагмент кода, который может выполняться независимо от других фрагментов (задач). Как PLINQ, так и TPL предлагают API для создания задач. При этом PLINQ разбивает запрос на отдельные запросы (задачи), а TPL разбивает задачу на подзадачи, разбивая циклы или последовательность блоков кода на задачи. Для синхронизации имеются соответствующие примитивы.

Параллельный интегрированный язык запросов (Parallel Language-Integrated Query, PLINQ) - является параллельной реализацией LINQ. В отличие от LINQ PLINQ поддерживает параллельное выполнение запросов, используя, все доступные ядра/процессоры.

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

Компонентная модель .NET. Компонент .NET представляет собой прекомпилированный MSIL, который может быть помещен в любой другой MSIL компонент или клиентскую программу без выполнения компиляции.

Компонент .NET представляет собой прекомпилированный самоописываемый MSIL модуль, построенный на базе одного или более классов или модулей, расположенных в DLL файле сборки (DLL assembly file) [143].

Сборки представляют собой базовые строительные блоки, которые обеспечивают развертывание и выполнение приложений .NET.

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

Принципиальным отличием сборок от EXE- и DLL-файлов является то, что метаданные, описывающие содержимое, при работе со сборками хранятся внутри сборок, а при работе с EXE- и DLL-файлами метаданные хранятся в отдельных файлах.

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

• 
  манифест;
  
• 
  метаданные;
  
• 
  код приложения;
  
• 
  ресурсы.
  

Манифест (manifest) содержит имя сборки, информация о версии, информация о файлах, входящих в состав сборки и безопасности.

Метаданные (metadata)- это информация о типах, объявленных в сборке, имена типов, их областях видимости, базовые классы и реализуемые интерфейсы.

Код приложения — это код, который компилируется в формат промежуточного языка Microsoft (Microsoft Intermediate Language, MSIL) и реализует типы, описываемые метаданными.

Ресурсы – это графические файлы, курсоры и статический текст

Наличие в сборке метаданных и декларации означает, что сборка является полностью самодокументированной.

Кроме того, сборка также может содержать неуправляемый код и неуправляемые данные. Существует множество способов группировки элементов в сборке. Обязательным элементом сборки является манифест.

Сборка может представлять собой либо один физический файл, либо может быть распределен среди нескольких файлов. Чаще всего сборка оформляется в виде одного файла. Такой файл называют переносимым исполняемым файлом (Portable Executable - РЕ). Сборки, состоящие из одного файла обычно включают декларацию, метаданные и код MSIL.

Если сборка содержит несколько файлов, ее элементы размещаются в отдельных модулях.

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



Рис. 10.8. Типовая структура однофайловой сборки
Типовая структура однофайловой сборки показана на рис. 10.8, а многофайловой – на рис. 10.9.

Рис. 10.9. Типовая структура многофайловой сборки

Среда CLR работает с многофайловой сборкой как с единым объектом.

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

В .NET имеется много разных типов компонентов. В частности, можно выделить «визуальные» и «невизуальные» компоненты. Визуальные компоненты имеют иконки и в процессе разработки их можно перетаскивать в проект.

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

В качестве клиента может выступать как другой компонент, так и клиентское приложение.

.NET component может быть либо локальным (local component), либо распределенным (distributed component). Локальный компонент ((.dll) доступен локально (внутри домена приложения) на одном хосте. Удаленный (распределенный) компонент может быть доступен удаленно из других доменов приложений на том же или другом хосте. Домен приложений – это легковесный процесс, который может быть запущен и остановлен независимо от других легковесных процессов.

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

.NET DLL component может быть установлен как частный компонент (private component), который может работать только с определенным клиентом, либо как разделяемый (shared public component), которому неизвестен клиент. DLL компоненты можно включать в любые приложения .
10.5. OSGi

OSGi (Open Services Gateway Initiative) — спецификация динамической модульной шины для создания Java-приложений. Основным разработчиком является консорциум OSGi Alliance [144].

Инициатива OSGi была выдвинута в 1999г., группой 15 компаний. Идея состояла в том, чтобы множество устройств, начиная от бытовых систем и заканчивая промышленными роботами, могли взаимодействовать между собой через Интернету посредством использования универсального шлюза, построенного на основе технологии Java.

В результате должен был появиться отраслевой стандарт платформы для приложений Java, позволяющей нескольким приложениям безопасно работать с одной виртуальной машиной Java (Java Virtual Machine, JVM), кроме того, приложения могут совместно работать с такими ресурсами как данные, функции и нити (threads). Сервисная платформа OSGi должна была позволять создавать приложения из небольших, взаимодействующих друг с другом (collaborative) компонентов. Изначально OSGi разрабатывалась для использования в составе встроенных систем различного назначения, однако постепенно область применения расширилась и данная спецификация стала использоваться для построения как десктоп-приложений, так и корпоративных приложений.

Следует заметить, что данная модель компонентных приложений является прямым конкурентом платформе Microsoft .Net,

Версии стандарта OSGi. Первая версия спецификации OSGi появилась в мае 2000 года, вторая – в октябре 2001 года, третья – в октябре 2006 года. На момент написания книги последней была версия 4.3, которая появилась в апреле 2011 года. В марте 2010 появилась спецификация OSGi для корпоративных систем (Enterprise Specification).

Имеется достаточно много как бесплатных, так и распространяемых реализаций OSGi, относящимся к разным версиям спецификации. Среди наиболее популярных реализаций стандарта с открытым исходным кодом: Apache Felix, Knopflerfish, Concierge OSGi и Equinox.

Apache Felix —фреймворк, являющийся реализацией спецификации OSGi Release 4. Основой данного фреймворка является проект Oscar из состава ObjectWeb, позднее этот стал проектом верхнего уровня некоммерческой организации Apache Software Foundation.

Knopflerfish — некоммерческая организация, развивающая технологию OSGi. Проект представляет собой свободную сертифицированную реализацию спецификации OSGi R4 v4.2, а также связанные с ней инструменты и приложения.

Concierge — фреймворк, реализующий спецификацию OSGi (Open Service Gateway Initiative) R3, предназначен для устройств с ограниченными ресурсами, таких как мобильные и встраиваемые системы.

Equinox — проект Eclipse который представляет собой фреймворк, реализующий спецификацию OSGi версии 4. Equinox по свой сути является системой поддержки плагинов, которая позволяет разработчикам создавать приложения в виде набора бандлов, использующих общие сервисы и инфраструктуру. В версии Eclipse 3.0 Equinox заменил старую систему поддержки плагинов, использовавшуюся в более ранних версиях. Таким образом, технология OSGi предоставляет сервис-ориентированную платформу с поддержкой модульности для разработки приложений.

На основе Equinox построена среда разработки Eclipse 3.0+, претендующая на звание отраслевого стандарта компонентной сборки программ, что позволило использовать Eclipse не только как среду разработки (IDE), но и как платформу для создания приложений различного профиля и уровня сложности, в ядре которой OSGi используется для управления работы встраиваемых плагинов (plugin).

Платформа OSGi имеет две составляющие: OSGi фреймворк (OSGi framework) и стандартные сервисы OSGi (OSGi standart services). Фреймворк играет основную роль, он является средой, в которой исполняются приложения и которая обеспечивает предписываемую стандартом OSGi функциональность. Стандартные сервисы определяют интерфейс для общих задач, например запуск сервлетов, управление питанием, управление устройствами, ведение протокола работы и т.д.

Архитектура OSGi. Фреймворк является ядром сервисной платформы OSGi, которая обеспечивает безопасную управляемую среду исполнения, которая загружать и исполнять приложения, которые называют bundles (модули).OSGi-совместимые устройства могут загружать, устанавливать и удалять модули в процессе функционирования, при этом ядро автоматически отслеживает зависимость между модулями.

OSGi имеет многослойную архитектуру (рис. 10.10), при этом в рамках OSGi выделяются следующие слои (layers):

- уровень безопасности;

- уровень управления модулями системы;

- уровень управления жизненного цикла OSGi компонент;

- уровень управления сервисами.



Рис. 10.10

Уровень безопасности (Security Layer) реализует модель безопасности Java 2.

Уровень управления модулями системы (Module layer) – уровень управления модулями системы, связанный с компоновкой, разделением и совместным использованием кода. Основной задачей этого уровня является предоставление другим компонентам доступа к заданному внешнему интерфейсу компонента, скрывая при этом его внутреннюю реализацию, и определение модулей, которые необходимы для успешного функционирования данного компонента (то есть определение модулей, наличие которых необходимо). Чтобы различать традиционные модули java и OSGi модули, было введено понятие bundle, который в реально является обычным архивом jar с указанной в файле META-INF/MANIFEST дополнительной конфигурационной информацией;

Уровень управления жизненного цикла (Lifecycle layer) – это уровень, который предоставляет возможность управлять жизненным циклом OSGi компонента и в определенные моменты производить необходимые действия, такие как установление соединения с базой данных или запуск фоновый процесса при инициализации работы модуля, при этом OSGi-компонент в каждый конкретный момент времени находится в одном из следующих 6 состояний:

- модуль установлен (installed);

- разрешены все зависимости (resolved);

- запуск модуля (starting);

- модуль запустился (active);

- модуль остановлен (stopping);

- модуль удален (stopping).

Уровень управления сервисами (Service Layer) – это уровень управления сервисами, который отвечает за динамическую зарегистрацию интерфейсов в реестре сервисов OSGi (SOA Registry), что позволяет другим компонентам динамически находить и использовать зарегистрированные сервисы.

OSGi часто называют «малой СОА» или «SOA in small», поскольку изначально был ориентирован преимущественно на работу с периферийными устройствами [145].