Ответы на вопросы upd / Воп_ сети2012 не кратко upd

используется для создания файлов и файлов конфигурации приложений (ACF), необходимых для дистанционного вызова процедуры интерфейсов (RPC) и COM/DCOM интерфейсов.

COM IDL — язык описания интерфейсов между модулями COM. Является преемником языка IDL в технологии DCE (англ. среда распределѐнных вычислений) — спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open

Group).

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

Применительно к компонентам, когда речь идет о способах сохранения и восстановления их состояния используют термин перманентными (persistent). Перманентность данных позволяет объекту прекращать свое исполнение, а когда повторно появляется необходимость продолжить работу с компонентом, то экземпляр объекта будет создан снова и продолжает работу с того же места, просто загрузив перманентные данные.

Механизм, с помощью которого объекты сохраняют и загружают свои перманентные данные, иногда называют сервисом перманентности (persistent service).

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

СОМ-объекты предоставляют два разных наборов интерфейсов для поддержки перманентности. Первый предоставляет СОМ-объектам возможность работы со структурированным хранилищем (Structured Storage). Второй набор стандартных интерфейсов позволяет клиенту управлять перманентностью COM-объекта. COM-объект может поддерживать один или несколько таких интерфейсов, объединенных под общим названием интерфейсы

IPersist*.

111

37. Общая характеристика JEE

Java Platform, Enterprise Edition, сокращенно Java EE (до версии 5.0 — Java 2

Enterprise Edition или J2EE) — набор спецификаций и соответствующей документации для языка Java, описывающей архитектуру серверной платформы для задач средних и крупных предприятий.

Спецификации детализированы настолько, чтобы обеспечить переносимость программ с одной реализации платформы на другую. Основная цель спецификаций — обеспечить масштабируемость приложений и целостность данных во время работы системы. J2EE во многом ориентирована на использование еѐ через веб как в интернете, так и в локальных сетях. Вся спецификация создаѐтся и утверждается через JCP (Java Community Process) в

рамках инициативы Sun Microsystems Inc.

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

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

112

38. Обращение к удаленным объектам. RMI.

RMI (англ. Remote Method Invocation) — программный интерфейс вызова удаленных методов в языке Java.

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

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

Типичная реализация модели Java-RMI, использующая объекты 'заглушки'(stub) и 'скелета'(skeleton).

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

При вызове метода удаленного объекта на самом деле вызывается обычный метод языка Java, инкапсулированный в специальном объекте-заглушке (stub), который является представителем серверного объекта. Заглушка находится на клиентском компьютере, а не на сервере. Она упаковывает параметры удаленного метода в блок байтов. Каждый параметр кодируется с помощью алгоритма, обеспечивающего независимость от аппаратуры. Например, числа всегда передаются в порядке, при котором сначала передается старший байт (big-endian). При этом объекты подвергаются сериализации. Процесс кодирования параметров называется развертыванием параметров (parameter marshaling). Основная цель развертывания параметров — преобразование их в формат, пригодный для передачи параметров от одной виртуальной машины к другой.

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

идентификатор удаленного объекта; описание вызываемого метода; развернутые параметры.

Затем метод заглушки посылает эту информацию серверу. Далее объектполучатель выполняет для каждого вызова удаленного метода следующие действия:

свертывание параметров; поиск вызванного объекта; вызов заданного метода;

извлечение и развертывание возвращаемого значения или исключения, сгенерированного данным методом;

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

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

113

возвращаемым значением метода заглушки. Если удаленный метод возвращает исключение, то объект-заглушка повторит его в среде объекта-клиента.

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

int q=centralWarehouse.getQuantity(―SuperSucker 100 Vacuum Cleaner‖);

Для доступа к удаленным методам клиентский код всегда использует объектные переменные типы interface. Например, с приведенным выше методом может быть связан следующий интерфейс:

interface Warehouse {

int getQuantity(String description) throws RemoteException; Product getProduct(Customer cust) throws RemoteException;

…

}

Объявление переменной для объекта, который реализует этот интерфейс, будет выглядеть так:

Warehouse centralWarehouse = …;

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

При передаче объекта другой программе (он может быть параметром либо возвращаемым значением удаленного метода) нужен файл класса, соответствующий этому объекту. Например, метод, который возвращает значение типа Product. При компиляции клиентской программы должен быть сгенерирован файл класса Product.class.

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

114

39. Сервлеты и JSP.

Сервлет является Java-интерфейсом, реализация которого расширяет функциональные возможности сервера. Сервлет взаимодействует с клиентами посредством принципа запрос-ответ.

Хотя сервлеты могут обслуживать любые запросы, они обычно используются для расширения веб-серверов. Для таких приложений технология Java Servlet определяет HTTP-специфичные сервлет классы.

Пакеты javax.servlet и javax.servlet.http обеспечивают интерфейсы и классы для создания сервлетов.

Жизненный цикл сервлета состоит из следующих шагов:

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

Контейнер вызывает метод init(). Этот метод инициализирует сервлет и вызывается в первую очередь, до того, как сервлет сможет обслуживать запросы. За весь жизненный цикл метод init() вызывается только однажды.

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

В случае если контейнеру необходимо удалить сервлет, он вызывает метод destroy(), который снимает сервлет из эксплуатации. Подобно методу init(), этот метод тоже вызывается единожды за весь цикл сервлета.

JSP (JavaServer Pages) — технология, позволяющая веб-разработчикам легко создавать содержимое, которое имеет как статические, так и динамические компоненты. По сути, страница JSP является текстовым документом, который содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов HTML, SVG, WML, или XML, и JSP элементы, которые конструируют динамическое содержимое. Кроме этого могут использоваться библиотеки JSP тегов, а также EL (Expression Language), для внедрения Java-кода в статичное содержимое JSPстраниц.

JSP — одна из высокопроизводительных технологий, так как весь код страницы транслируется в java-код сервлета с помощью компилятора JSP страниц Jasper, и затем компилируется в байт-код виртуальной машины java (JVM). Контейнеры сервлетов, способные исполнять JSP страницы, написаны на языке Java, который может работать на различных платформах. JSP страницы загружаются на сервере и управляются из структуры специального Java server packet, который называется Java EE Web Application, в большинстве своѐм упакованные в файловые архивы .war и .ear.

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

115

JavaServer Pages (JSP) позволяют отделить динамическую часть страниц от статического HTML. Процедура довольно проста, создаѐте обычный код HTML (статический), а динамическую часть заключаете в специальные теги "<% %>".

Имя вашего хоста: <%= request.getRemoteHost() %>

JSP страницы имеют расширение .jsp и размещаются там же, где и обычные Web страницы. Структура таких страниц может состоять из пяти конструкций: HTML, комментарии, скриптовые элементы, директивы и действия. JSP страница при компиляции преобразуется в обычный сервлет со статическим содержимым, которое направляется в поток вывода, связанный с методом service. Поэтому при первом запросе этот процесс может вызвать некую задержку, но в большинстве своѐм незаметную первому пользователю. Комментарии в документе или программе служат к объяснению содержимого. Они не являются причиной замедления программы, так как транслятор и исполнитель их игнорируют. Скриптовые элементы позволяют вам указать код на языке Java, который впоследствии станет частью конечного сервлета, директивы дадут вам возможность управлять всей структурой сервлета, а действия служат для задания существующих используемых компонентов, а также для контроля над поведением движка JSP. Для упрощения работы со скриптами имеются заранее определѐнные переменные, такие как request, response, pageContext, session, out, application, config, page, exception.

Комментарии используются для пояснения исходного текста программы. В JSP-страницах комментарии можно разделить на две группы:

комментарии исходного кода JSP комментарии HTML-разметки.

Комментарии исходного кода JSP отмечаются специальной последовательностью символов: <%-- в начале и --%> в конце комментария. Данный вид комментариев удаляется на этапе компиляции JSP-страницы и потому не доступны пользователям.

Спецификация JSP различает три типа скриптовых элементов: Объявления <%! одна или несколько деклараций %> Выражения <%= одно выражение %> Скриплеты <% скриплет %>

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

Выражения JSP применяются для того, чтобы вставить значения Java непосредственно в вывод. Выражения Java вычисляются, конвертируются в строку и вставляются в страницу. Эти вычисления проходят во время выполнения (то есть при запросе страницы), а потому существует полный доступ к информации о самом запросе. В выражениях можно использовать постоянные, переменные, вызовы различных методов. Все выражения, вне зависимости от сложности их содержимого, вычисляются в один результат или число. JSP страницы полагаются на JSP Writer, который берѐт любой результат выражения, переводит его в тип String (текстовый) и заносит в буферную память.

Если вы хотите сделать что-то большее чем просто вставку выражений, то скриплеты JSP дадут вам возможность вставить любой код в метод сервлета, который будет создан при обработке данной страницы. В данном случае Вы

116

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

117

40. EJB.Session, Entity. Message Driven Beans.

Enterprise JavaBeans (также часто употребляется в виде аббревиатуры EJB)

— спецификация технологии написания и поддержки серверных компонентов, содержащих бизнес-логику. Является частью Java EE.

Эта технология обычно применяется, когда бизнес-логика требует как минимум один из следующих сервисов, а часто все из них:

поддержка сохранности данных (persistence); данные должны быть в сохранности даже после остановки программы, чаще всего достигается с помощью использования базы данных

поддержка распределѐнных транзакций поддержка конкурентного изменения данных и многопоточность поддержка событий

поддержка именования и каталогов (JNDI) безопасность и ограничение доступа к данным

поддержка автоматизированной установки на сервер приложений удалѐнный доступ

Каждый EJB компонент является набором Java классов со строго регламентированными правилами именования методов (верно для EJB 2.0, в EJB 3.0 за счет использования аннотаций выбор имен — свободный). Бывают трех основных типов:

объектные (Entity Bean), перенесены в спецификацию Java Persistence API сессионные (Session Beans), которые бывают

без состояния (stateless)

с поддержкой текущего состояния сессии (stateful)

один объект на все приложение (singleton), начиная с версии 3.1 управляемые сообщениями (Message Driven Beans) — их логика является

реакцией на события в системе

118

41. Транзакции.

Транза́кция (англ. transaction) — группа последовательных операций с базой данных, которая представляет собой логическую единицу работы с данными. Транзакция может быть выполнена либо целиком и успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще и тогда она не должна произвести никакого эффекта. Транзакции обрабатываются транзакционными системами, в процессе работы которых создаѐтся история транзакций.

Различают последовательные (обычные), параллельные и распределѐнные транзакции. Распределѐнные транзакции подразумевают использование больше чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit — двухфазный протокол фиксации транзакции). Также, в некоторых системах реализованы автономные транзакции, или подтранзакции, которые являются автономной частью родительской транзакции.

Одним из наиболее распространѐнных наборов требований к транзакциям и транзакционным системам является набор ACID (Atomicity, Consistency,

Isolation, Durability).

Atomicity — Атомарность

Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все еѐ подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаѐтся полностью завершить, результаты всех еѐ до сих пор произведѐнных действий будут отменены и система вернѐтся в исходное состояние.

Consistency — Согласованность

Одно из самых сложных и неоднозначных свойств из четвѐрки ACID. В соответствии с этим требованием, система находится в согласованном состоянии до начала транзакции и должна остаться в согласованном состоянии после завершения транзакции. Не нужно путать требование согласованности с требованиями целостности (integrity). Последние правила являются более узкими и, во многом, специфичны для реляционных СУБД: есть требования целостности типов (domain integrity), целостности ссылок (referential integrity),

целостности сущностей (entity integrity), которые не могут быть нарушены физически в силу особенностей реализации системы.

Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счѐта, сумме, зачисляемой на другой. Это бизнес-правило и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какаялибо транзакция произведѐт списание, но не произведѐт зачисление, то система останется в некорректном состоянии и свойство согласованности будет нарушено.

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

119

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

Isolation — Изолированность

Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на еѐ результат. Это свойство не соблюдается на уровне изолированности Read Committed и ниже.

Durability — Надежность

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

В идеале транзакции разных пользователей должны выполняться так, чтобы создавалась иллюзия, что пользователь текущей транзакции — единственный. Однако в реальности, по соображениям производительности и для выполнения некоторых специальных задач, СУБД предоставляют различные уровни изоляции транзакций. Уровни описаны в порядке увеличения изоляции транзакций и надѐжности работы с данными

0 — Неподтверждѐнное чтение (Read Uncommitted, Dirty Read, грязное чтение) — чтение незафиксированных изменений своей транзакции и параллельных транзакций, возможны нечистые, неповторяемые чтения и фантомы

1 — Подтверждѐнное чтение (Read Committed) — чтение всех изменений своей транзакции и зафиксированных изменений параллельных транзакций, нечистые чтения невозможны, возможны неповторяемые чтения и фантомы;

2 — Повторяемое чтение (Repeatable Read, Snapshot) — чтение всех изменений своей транзакции, любые изменения, внесѐнные параллельными транзакциями после начала своей, недоступны, нечистые и неповторяемые чтения невозможны, возможны фантомы;

3 — Упорядоченный — (Serializable, сериализуемый) — упорядоченные (сериализуемые) транзакции. Идентичен ситуации, при которой транзакции выполняются строго последовательно, одна после другой, то есть результат действия которых не зависит от порядка выполнения шагов транзакции (запрещено чтение всех данных, изменѐнных с начала транзакции, в том числе и своей транзакцией). Фантомы невозможны.

Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы их поддерживать.

120