14. Платформа j2ee. (основные технологии стека). Enterprise JavaBeans (ejb), обобщенная архитектура, принципы функционирования и структура программного обеспечения. Полина

J2EE включает в себя стандарты следующих основных технологий:

1) Технология Java Servlet позволяет определить классы сервлетов. Класс сервлета расширяет возможности серверов, доступные клиентским приложениям при использовании ими модели программирования "запрос - ответ".

2) Технология JavaServerPages позволяет встраивать фрагменты кода сервлета прямо в текстовые документы.

3) Технология Enterprise JavaBeans. Specification EJB описывает каким образом реализуется бизнес-логика внутри EJB-системы, как взаимодействуют между собой клиенты и серверы, как EJB-системы взаимодействуют с другими системами и какова роль различных компонент (бинов) этой системы.

4) J2EE Connector Architecture используется поставщиками J2EE-инструментов и системными интеграторами для создания адаптеров ресурсов, поддерживающих доступ к информационной системе предприятия.

5) JavaMessageService (JMS) представляет собой стандарт обмена сообщениями, позволяющий компонентам J2EE-приложения создавать, посылать, принимать и читать сообщения. Он обеспечивает двустороннее, надежное, асинхронное распределенное соединение.

6) Java Authentication and Authorization Service (JAAS) предоставляет возможность приложению J2EE аутентифицировать и авторизовывать определенного пользователя или группу пользователей.

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

- Приложение должно быть масштабируемым; - Для гарантии целостности данных требуются транзакции; - У приложения будут разные клиенты.

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

В EJB под компонентом подразумевается зерно (Bean), а под Enterprise подразумевают «корпоративный». EJB делит компоненты (зерна) на несколько типов:

· сессионные (Session Beans), которые могут быть

/ stateful - с сохранением текущего состояния; /stateless - без сохранения состояния; /singleton - один объект для всех приложений (начиная с EJB версии 3.1).

· управляемые сообщениями (Message Driven Beans) - их логика является реакцией на события в системе;

· объектные (Entity Bean) - определены в спецификации JPA (Java Persistence API) entities и используются для хранения данных.

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

EJB stateful автоматически сохраняет свое состояние между обращениями к нему от одного и того же клиента, и завершает свое существование либо по таймауту, либо по явному запросу клиента (корзина с покупками в интернет-магазине).

EJB stateless не хранят никакой информации о своем состоянии и являются прикладными службами, которые выполняют все необходимые действия в рамках запроса (Перевод средств на кредитную карту). На основе проектируются WEB-сервисы.

EJB singleton используются совместно всеми клиентами, имеющими к ним доступ, и продолжают свое существование на протяжении всего времени работы приложения. Сохраняет свое состояние (мспользуется в интернет-магазине для реализации скидки).

Сеансовые компоненты могут вызываться локально или удаленно, посредством Java RMI. Компоненты-одиночки и компоненты без сохранения состояния могут также экспортироваться в виде веб-служб SOAP (Simple Object Access Protocol) или REST (Representational State Transfer).

MDB (Message-Driven Bean) вызываются для обработки отправленных на сервер сообщений, что

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

EJB тесно связан с двумя спецификациями: JPA, которая является стандартом хранения данных для Java EE и CDI (Contexts and Dependency Injection) которая обеспечивает возможность внедрения зависимостей и предоставляет службы управления контекстом для всех компонентов Java EE, включая EJB.

Возможность автоматического сохранения объектов в реляционной БД с использованием технологии объектно-реляционного маппинга (ORM) - так называемый механизм работы с persistence объектами, является одним из главных достоинств EJB. EntityManager API - это интерфейс, который связывает класс сущности приложения (Entity Bean) и её представления в БД. EntityManager знает, как нужно добавлять сущности в БД, обновлять и удалять их, а также предоставляет механизмы для настройки производительности, кэширования, транзакций и т.д. Для этого используется язык запросов JPQL, очень похожий на SQL.

Согласно спецификации EJB3 контейнер предоставляет службы, применимые только к сеансовым компонентам и MDB. Операция добавления компонента EJB3 в контейнер называется развертыванием (deployment). После того, как EJB-компонент благополучно развернут в контейнере, он готов к использованию приложениями. EJB-container обеспечивает компоненты EJB такими службами, как обработка транзакций, поддержка безопасности, удаленные взаимодействия и веб-службы.

15. Контейнер EJB, понятие, назначение, основные функции. Примеры реализации класса и методы управления жизненным циклом Бина (по версии EJB 2.х). Модель разработки приложения на основе EJB 2.0 (основные объекты, связи и последовательность шагов для организации вызова методов бизнес-логики). ЛИЗА

EJB Контейнер представляет из себя среду времени выполнения, которая содержит и запускает EJB компоненты и предоставляет набор стандартных служб для этих компонент. Обязанности EJB Контейнера четко определены в спецификации, чтобы обеспечить нейтралитет производителя. EJB контейнер предоставляет низкоуровневое “обслуживание” EJB, включая распределенные транзакции, безопасность, управление циклом жизни компонента, кэширование, нити процессов и управление сессиями. Поставщик EJB Контейнера отвечает за предоставление EJB Контейнера.

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

· управление циклом жизни компонента – его созданием, инициализацией, сохранением его состояния в базе данных, если это необходимо;

· возможность поиска клиентом нужных ему объектов;

· гарантию того, что вызов методов происходит в контексте нужной транзакции;

· базовый уровень обеспечения безопасности;

· наличие инструментов разработчика, например, компилятора для генерации стабов.

· Обеспечение безопасности – обеспечения защиты данных за счет предоставления доступа только для авторизованных клиентов и только к разрешеным методам.

· Обеспечение удаленных вызовов – Контейнер берет на себя все низкоуровневые вопросы обеспечения взаймодействия и организации удаленных вызовов.

· Управление циклом жизни – клиент создает и уничтожает экземпляры компонентов. Тем не менее, контейнер для оптимизации ресурсов и повышения производительности системы может выполнить например: активацию и деактивизацию этих компонентов, создание их пулов и т.д.

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

• Сеансовые объекты EJB — это объекты EJB, не сохраняющиеся в энергонезависимой памяти. Они делятся на два вида: с сохранением состояния и без сохранения состояния.

  • Сеансовые объекты EJB с состоянием представляют отдельного клиента и хранят специфичную для него часть информации о сеансе (она называется "состояние диалога") между вызовами методов и транзакциями. Эти объекты существуют в течении одного сеанса связи между клиентом и сервером.

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

• Сущностные объекты EJB — это объекты EJB, содержащие данные, хранимые в энергонезависимой памяти, например, в различных хранилищах данных. Каждый сущностный объект EJB обладает собственным идентификатором. Сущностные объекты, управляющие своим хранением, называются "сущностные объекты с собственным управлением хранением" (BMP entity beans — Bean-Managed Persistence entity beans). Сущностные объекты, передающие управление хранением своему контейнеру EJB, называются "сущностные объекты с хранением, управляемым контейнером EJB" (CMP — container-managed persistence).

• Объекты EJB, управляемые сообщениями — это объекты EJB, принимающие и обрабатывающие сообщения JMS. В отличие от сеансовых или сущностных объектов EJB, у управляемых сообщениями объектов EJB нет интерфейсов. Доступ к ним осуществляется только через обмен сообщениями, и они не сохраняют диалоговых состояний. Управляемые сообщениями объекты EJB допускают асинхронный обмен информацией между очередью и обработчиком событий, а также обеспечивают отделение процесса обработки сообщений от бизнес-логики.

16. Удаленное взаимодействие в EJB (по модели EJB 2.х) Понятие, определение назначение и структура собственного (HOME) удаленного (Remote) (примеры кода реализации на Java для различных типов бинов). КСЮША

Компоненты EJB имеют, вольно выражаясь, два внешних описания (интерфейса). Через них, собственно, клиент и взаимодействует с Вашим компонентом.

Home-интерфейс, является точкой входа в Ваш компонент или фабрикой компонента. Другими словами любое начало взаимодействия с Вашими компонентами происходит через Home-интерфейсы. Клиент обращается к интерфейсу и создает через него экземпляры (объекты), которые обслуживают данный компонент. А в конце своей работы он их уничтожает.

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

На стороне клиента Remote-интерфейс и Home-интерфейс оформлены в виде классов, которые скрывают сетевые взаимодействия на основе RMI с сервером приложений.

Example 1

@Remote

public interface SessionBeanRemote {

String getResult();

String getAddress();

String getCompanyname();

}

@Stateless

public class SessionBeanBean implements SessionBeanRemote {

public String getResult() {

return "Hello World";

}

public String getAddress() {

return "Sec-3,D-16/116,Rohini";

}

public String getCompanyname() {

return "Roseindia.net Pvt.Ltd.";

}

}

public interface Bean30RemoteHome extends EJBHome{

public Bean30Remote create() throws CreateException, RemoteException;

}

Example 2

public interface BidManager{

void addBid(Bid bid);

List<Bid> getBids(Item item);

}

@Local

public interface BidManagerLocal extends BidManager {

void cancelBid(Bid bid);

}

@Remote

public interface BidManagerRemote extends BidManagerLocal {}

@WebService

public interface BidManagerWS extends BidManager {}

17. Дескриптор развертывания, назначение, структура и семантика представления, общие принципы организации кода в EJB 2.х. и развертывания бинов в контейнере. Пример описания кода дескриптора развертывания. ЯНА

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

Описатель развёртывания является XML файлом, который содержит информацию относительно вашего EJB. Использование XML позволяет установщику легко менять атрибуты EJB. Поскольку XML является метаязыком, то для описания каждого конкретного класса документов нужно создать свой язык - в частности, определить набор используемых тегов и правила взаимоотношений между ними. Такой язык называется Document Type Definition (DTD). Конфигурационные атрибуты, определённые в описателе развертывания, включают:

· Имена Домашнего и Удаленного интерфейса, которые требуются для вашего EJB;

· Имя для публикации в JNDI для вашего Домашнего интерфейса EJB;

· Транзакционные атрибуты для каждого метода вашего EJB;

· Контрольный Список Доступа для авторизации.

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

<session> - используется для обознчения session-Компонентов

<entity> - используется для обозначения Entity-Компонентов

Внутри области тега <session> могут использоваться другие теги:

<ejb-class> - имя класса реализации.

<home> - имя home-интерфейса.

<remote> - имя remote-интерфейса.

<session-type> - показывает, является ли session-Компонент stateful- или stateless-Компонентом.

<transaction-type> - показывает, используется ли для Компонента CMT или BMT.

<trans-attribute> - задает значение атрибутов транзакции для каждого метода.

<timeout> - значение тайм-аута для session-Компонента.

Пример:

<ejb jar>

<enterprise beans>

<session>

<description>

XML deployment descriptor created from file:

D:\Kodiak\kodiak04\ejb_ea_0_4\examples\cart\cart.ser

</description>

<ejb-name>cart</ejb-name>

<home>CartHome</home>

<remote>Cart</remote>

<ejb-class>CartBean</ejb-class>

<session-type>Stateful</session-type>

<transaction-type>Container</transaction-type>

</session>

</enterprise-beans>

<assembly-descriptor>

<container-transaction>

<method>

<ejb-name>cart</ejb-name>

<method-name>*</method-name>

</method>

<trans-attribute>NotSupported</trans-attribute>

</container-transaction>

<container-transaction>

<method>

<ejb-name>cart</ejb-name>

<method-name>purchase</method-name>

</method>

<trans-attribute>Required</trans-attribute>

</container-transaction>

</assembly-descriptor>

</ejb-jar>

18. JNDI, структура, назначение, функционирование. Использование и основное назначение (роль) JNDI-методов в организации взаимодействия клиента и сервера в EJB. САША

Java Naming and Directory Interface (JNDI) - это API для доступа к службам имен и каталогов. Прежде чем погружаться в JNDI, поясним, о каких службах идет речь. Службой имен, в самом широком смысле, называют систему, управляющую отображением множества имен во множество объектами. Зная имя объекта в системе, клиент может получить доступ к этому объекту или ассоциировать с этим именем другой объект. Примером является DNS, служба доменных имен.

JNDI состоит из следующих пяти пакетов:

· javax.naming - содержит основные классы и интерфейсы, необходимые для взаимодействия со службами имен. В частности, интерфейс Context для поиска объектов, привязки объекта к имени, создания и удаления контекстов.

· javax.naming.directory - расширяет пакет javax.naming средствами взаимодействия со службами каталогов. Определяет интерфейс DirContext, позволяющий работать с атрибутами объектов каталога.

· javax.naming.event - определяет классы и интерфейсы событий, происходящих в каталоге, а также средства перехвата этих событий.

· javax.naming.ldap - предоставляет средства для работы со специфическими возможностями LDAPv3, редко используется, и в большинстве случаев достаточно использовать пакет javax.naming.directory.

· javax.naming.spi определяет способ интеграции новых систем имен или каталогов с JNDI, чтобы клиенты могли пользоваться этими службами из Java-программ средствами JNDI.

JNDI используется в Enterprise JavaBeans в качестве службы указания имен для EJB компонент в сети и других службах контейнера, таких как транзакции. JNDI работает очень похоже с другими стандартами, такими как CORBA Naming (сервис именования)

При развертывании бина имя для публикации в JNDI домашнего интерфейса EJB берется из дескриптора развертывания.

Когда клиентская программа хочет вызвать EJB, она должна найти EJB компонент внутри JNDI и получить ссылку на домашний интерфейс EJB компонента. Домашний интерфейс используется для создания экземпляра EJB.

Когда у клиента EJB возникает потребность воспользоваться услугами EJB, он с помощью home-интерфейса создаёт EJB. Клиент использует один из методов create(), которые определяет home-интерфейс. Реализация home-интерфейса осуществляется с помощью объекта, называющегося home-объектом. Экземпляр такого home-объекта создаётся на сервере и в качестве factory (построителя) предоставляется клиенту для создания бина.

Поиск Home-объекта

Клиент EJB определяет местонахождение home-объекта с помощью JNDI, так как ссылка на этот home-объект помещается в службе имён (naming service при развертывании соответствующих контейнеров с компонентами). Соответствующее местоположение и имя factory-класса для контекста JNDI предоставляется клиенту изначально. Кроме знания места и имени класса, клиент должен иметь представление о том, как найти этот home-объект в структуре дерева имён (naming tree).

На самом деле remote-интерфейс перенаправляет вызовы клиента собственно Компоненту EJB.

Вызов из web принципиально ничем не отличается

19. Сеансовые/Сессионные (Session) типы компонентов (бинов) EJB их особенности и применение. Пример реализации клиентской части сессионных бинов EJB (код на JAVA). НАСТЯ

Session beans - представляет одного клиента внутри сервера J2EE и - используется для построения бизнес-логики, которая может быть вызвана программным клиентом через локальный, удаленный или веб-интерфейс обслуживания клиентов. Для доступа к приложению, развернутого на сервере, клиент вызывает методы сессионного компонента. Сессионный компонент выполняет работу для своего клиента, защищая его от сложности, выполняя бизнес-задачи внутри сервера. Компоненты EJB выполняются внутри EJB-контейнера, который, в свою очередь, выполняется внутри EJB-сервера. Вызываются пользователем для совершения какой-либо бизнес-операции. Слово «сессионный» предполагает, что экземпляр компонента доступен только на время выполнения определенной задачи сервером, и безвозвратно уничтожается в случае аварии или остановки сервера. Для доступа к серверной части приложения, клиент вызывает методы сессионного компонента, выполняющего определенные бизнес-задачи внутри сервера.

Существует 3 типа session-beans: stateless и stateful, singleton (начиная с версии ejb 3.1).

EJB stateful автоматически сохраняет свое состояние между обращениями к нему от одного и того же клиента, и завершает свое существование либо по таймауту, либо по явному запросу клиента (корзина с покупками в интернет-магазине).

EJB stateless не хранят никакой информации о своем состоянии и являются прикладными службами, которые выполняют все необходимые действия в рамках запроса (Перевод средств на кредитную карту). На основе проектируются WEB-сервисы.

EJB singleton используются совместно всеми клиентами, имеющими к ним доступ, и продолжают свое существование на протяжении всего времени работы приложения. Сохраняет свое состояние (мспользуется в интернет-магазине для реализации скидки).

Сеансовые компоненты могут вызываться локально или удаленно, посредством Java RMI. Компоненты-одиночки и компоненты без сохранения состояния могут также экспортироваться в виде веб-служб SOAP (Simple Object Access Protocol) или REST (Representational State Transfer).

В качестве session bean может выступать обычный класс Java, но он должен удовлетворять следующим условиям:

1. Он должен иметь как минимум один метод;

2. Он не должен быть абстрактным;

3. Он должен иметь конструктор по-умолчанию;

4. Методы не должны начинаться с «ejb» (например ejbBean, ejbGoAtHome);

5. Свойства класса должны быть объявлены примитивами или реализовывать интерфейс Serializable.

SessionBean состоит из следующих элементов:

· Каждый сессионный бин должен иметь безнес интерфейс (business interface) (требование актуально до версии ejb 3.1) в котором декларируются бизнес методы, видимые клиентским приложениям.

· (bean class), который содержит реализацию бизнес-методов.

Session Beans интерфейс может иметь аннотацию:

@Remote - удаленный (business interface) - используеются разные виртуальные машины (даже если на одном хосте).

@Local - локальный (business interface) - используется одна и таже виртуальная машина (по умолчанию).

import javax.ejb.Local;

import java.math.BigDecimal;

@Local

public interface ConverterLocal {

BigDecimal dollarToYen(BigDecimal dollars);}

----------------------------------------------------

import java.math.BigDecimal;

import javax.ejb.Stateless;

@Stateless

public class Converter implements ConverterLocal {

private BigDecimal yenRate = new BigDecimal("83.0602");

@Override

public BigDecimal dollarToYen(BigDecimal dollars) {

BigDecimal result = dollars.multiply(yenRate);

return result.setScale(2,BigDecimal.ROUND_UP);}}

-----------------------------------------------------

эта вроде как уже часть сервера

import converter.ejb.*;

import java.io.*;

import javax.servlet.*;

import java.math.BigDecimal;

@WebServlet(name = "ConverterServlet", urlPatterns = {"/ConverterServlet"})

public class ConverterServlet extends HttpServlet {

@EJB

private ConverterLocal converter;

protected void processRequest(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

response.setContentType("text/html;charset=UTF-8");

try (PrintWriter out = response.getWriter()) {

String amount = request.getParameter("amount");

if(amount != null && amount.length() > 0){

BigDecimal d = new BigDecimal(amount);

BigDecimal yenAmount = converter.dollarToYen(d);

out.println("<!DOCTYPE html>");

out.println("<html>");

out.println("<head>");

out.println("<title>Конвертер валют</title>");

out.println("</head>");

out.println("<body>");

out.println("<p>Сумма в йенах = " + yenAmount + "</p>");

out.println("</body>");

out.println("</html>");}}}

@Override

protected void doGet(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

processRequest(request, response);}

@Override

protected void doPost(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

processRequest(request, response);}

@Override

public String getServletInfo() {

return "Short description";}}

20. Распределенные системы. Определение программной компоненты, и распределённой системы через понятие программные компоненты. Модели взаимодействия компонент, синхронные и асинхронные вызовы. Понятие МОМ, необходимость, значение и особенности использования промежуточной среды. ПОЛИНА

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

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

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

Промежуточное программное обеспечение (message-oriented middleware, MOM) — это класс ПО, предназначенный для объединения компонентов распределенного клиент-серверного приложения или целых сетевых приложений в единую информационную систему.

2 концепции взаимодействия программных компонент: обмен сообщениями между компонентами и вызов процедур или методов объекта удаленной компоненты по аналогии с локальным вызовом процедуры.

2 метода передачи сообщений от одной удаленной системы к другой:

1) непосредственный обмен сообщениями; (передача происходит напрямую, и она возможна только, если принимающая сторона готова принять сообщение в этот же момент времени). 2) использование очередей сообщений (используется посредник – менеджер очередей сообщений. Компонента посылает сообщение в одну из очередей менеджера, после чего она может продолжить свою работу. В дальнейшем получающая сторона извлечет сообщение из очереди менеджера и приступит к его обработке.).

Удаленный вызов процедур(RPC):

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

Распределенные события. 2 подхода :1) при тесно связанном событии происходит прямое уведомление одной стороны другой стороной. 2) слабо связанные события, когда источники события (издатели) не взаимодействуют напрямую с получателями событий (подписчиками). Промежуточная среда в этом случае должна предоставить сервис, позволяющий подписчику подписаться на какое-либо событие или отказаться от подписки, а издателю – инициировать событие для рассылки подписчикам.

Требования к распределенным системам

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

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

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

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

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

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

21. Message-Oriented Middleware, назначение, преимущества и модель использования таких средств. Организация клиент-серверного взаимодействия на JMS. Разработка и код клиентской части в JMS. ЛИЗА

Messaging System – это распределенная система, основанная на асинхронном обмене сообщениями (messages) между компонентами системы. В Messaging System приложения общаются не напрямую, а посредством MOM (промежуточного программного обеспечения). Если один компонент системы хочет послать сообщение другому компоненту, он посылает данное сообщение MOM, а уж MOM затем пересылает его адресату. Messaging делает возможным распределенное взаимодействие между слабо связанными компонентами. Компонент отправляет сообщение в пункт назначения, и получатель может забрать оттуда это сообщение. Однако отправитель и получатель не обязательно могут быть доступны в одно и то же время. Ни отправителю ничего не надо знать о получателе, ни получателю – об отправителе. Единственное, что должны знать обе стороны – это формат сообщения и его месторасположение (destination).

Перечислим указанные преимущества МОМ:

· Приложение, пославшее сообщение, не должно ждать ответа, и может продолжать свою текущую деятельность (только для асинхронного).

· Ни приложение, посылающее сообщение, ни адресат данного сообщения не обязаны быть активными в одно и то же время (только для асинхронного). Если адресат сообщения не активен, то MOM гарантирует, что сообщение будет доставлено, как только адресат станет активным.

· Компоненты системы не связаны напрямую друг с другом (decoupled), а потому возможно перенесение компонентов с одного хоста на другой в runtime без ущерба для работоспособности системы (только для асинхронного).