Шпаргалка по "Программированию"

1. Метод и этапы структурного анализа. Программные системы, их жизненный цикл. Анализ целевых и системных требований. Разработка требования к программным системам.

Метод и этапы структурного анализа.

На этапе анализа требований к системе формализуются, документируются и уточняются требования заказчика. Список требований включает:

1) совокупность условий, при которых будет эксплуатироваться  программная система;

2) описание выполняемых  системой функций;

3) ограничения на процессы  разработки;

На этапе анализа определяется архитектура системы, ее функции, распределение функций между аппаратурой и программным обеспечением.

На этапе проектирования исследуется структура системы и взаимосвязи ее компонентов. Проектирование часто определяют как процесс получения логической модели системы. Этап проектирования разделяется на два подэтапа:

1) проектирование структуры  и проектирование интерфейса  для отдельных компонентов;

2) детальное проектирование.

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

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

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

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

Программные системы, их жизненный цикл.

Программная система — система, состоящая из ПО и, возможно, компьютерного оборудования для его выполнения.

ЖЦ ПС определяется как период времени, который начинается с момента принятия решения о необходимости создания ПС и заканчивается в момент ее полного изъятия из эксплуатации.

ЖЦ ПС: приобретение, поставка, разработка, эксплуатация и сопровождение. Анализ целевых и системных требований.

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

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

Разработка требования к программным системам.

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

Требования могут выражаться в виде текстовых утверждений и графических моделей.

Фаза разработки требований может быть разбита на выявление требований, анализ, спецификация и  проверка правильности.

2. Метод и  стадии объектно-ориентированного  анализа и определение основных  абстракций и механизмов

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

Основные принципы (стадии) объектно-ориентированного анализа и проектирования:

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

Шаг второй. Объектно-ориентированный анализ предметной области. Это определение видов деятельности участников процесса и составлении концептуальной модели, которая отражает различные категории элементов предметной области.

Шаг третий. Эта деятельность называется объектно-ориентированным проектированием, при котором основное внимание сосредоточено на распределении обязанностей.

Ключевые абстракции

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

Определение ключевых абстракций включает в себя два процесса: открытие и изобретение.

Идентификация механизмов

Механизмы представляют шаблоны поведения.

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

3. Основы  проектирования программных систем, принципы аспекты проектирования. Разработка проектных решений  и проектных процедур.

Проектирование — итерационный процесс, при помощи которого требования к ПС транслируются в инженерные представления ПС. Модели анализа поставляют 3 типа информации.

• Информационная модель описывает информацию, которую, по мнению заказчика, должна обрабатывать ПС.
• Функциональная модель определяет перечень функций обработки.
• Поведенческая модель фиксирует желаемую динамику системы (режимы ее работы).

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

Принципы:

·Практическая полезность:

-деятельность должна быть целенаправленной.

-деятельность должна быть целесообразной.

-деятельность должна быть обоснованной и эффективной.

·Единство составных частей:

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

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

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

·Изменяемость во времени:

-учёт этапов жизненного цикла объекта;

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

Проектное решение - промежуточное или конечное описание объекта проектирования, необходимое и достаточное для рассмотрения и определения дальнейшего направления или окончания проектирования.

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

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

4. Этапы проектирования  программного обеспечения. Модульное  программирование. Нисходящее и  восходящее проектирование программ.

При проектировании сложных систем выделяется следующие этапы проектирования:

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

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

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

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

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

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

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

5. Принципы  объектно-ориентированного представления  программных систем. Классы, объекты, общая характеристика и отношения  между классами и объектами. Объектно-ориентированные  методы анализа и проектирования.

Принципы объектно-ориентированного представления программных систем:

·      Абстрагирование - каждая абстракция фиксирует основные характеристики объекта, которые отличают его от других видов объектов и обеспечивают ясные границы.

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

·      Иерархическая организация - упрощаются понимание проблем заказчика и их реализация — сложная система становится обозримой человеком.

 Объект — это конкретное представление абстракции. Объект обладает индивидуальностью, состоянием и поведением. Структура и поведение подобных объектов определены в их общем классе.

 Класс — описание множества объектов, которые разделяют одинаковые свойства, операции, отношения и смысл. Любой объект — просто экземпляр класса.

 Три основных отношения между классами:

1. Ассоциация
2. Агрегация и композиция
3. Наследование

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

Агрегация — отношение когда один объект является частью другого.

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

6. Языки визуального  моделирования. Язык UML (Unified Modeling Language). Отношения, механизмы и диаграммы. Приёмы моделирования.

Визуальное моделирование — способ создания программы для ЭВМ путём манипулирования графическими объектами вместо написания её текста.

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

Диаграмма в UML – это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями).

В UML выделяют следующие типы диаграмм:

– диаграммы вариантов использования–для моделирования бизнес-процессов организации.

– диаграммы классов– для моделирования статической структуры классов системы и связей между ними.

– диаграммы поведения системы

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

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

– диаграммы деятельностей– для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей.

– диаграммы реализации: диаграммы компонентов– для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения – для моделирования физической архитектуры системы.

Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями.

Механизмы расширения UML включают:

• стереотипы;
• помеченные значения;
• ограничения.

Приёмы моделирования

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

7. Моделирование  основных архитектурных решений  с применением UML, моделирование  поведения программных систем. Разработка  поведенческих моделей.

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

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

Архитектура - это совокупность существенных решений касательно:

• организации программной системы;
• выбора структурных элементов, составляющих систему, и их интерфейсов;
• поведения этих элементов, специфицированного в кооперациях с другими элементами;
• составления из этих структурных и поведенческих элементов все более и более крупных подсистем;
• архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы, кооперации и способ их объединения.

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

Архитектура может быть описана с помощью пяти взаимосвязанных видов:

Вид с точки зрения прецедентов, Вид с точки зрения проектирования

Вид с точки зрения процессов, Вид с точки зрения реализации

Вид с точки зрения развертывания

Существует два основных типа поведенческих сущностей:

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

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

Требования, предъявляемые к модели поведения:

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

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

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

8. Шаблоны (образцы) проектирования. Виды  шаблонов и их классификация, распределение «обязанностей» между  шаблонами.

Шаблон проектирования или паттерн(англ. Design pattern) – повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

Существует три типа шаблонов:

• Структурные шаблоны (адаптер, декоратор, заместитель, компоновщик, мост)
• Порождающие шаблоны (фабрика, одиночка, прототип, строитель) 
• Поведенческие шаблоны (шаблонный метод, итератор, команда, наблюдатель, посетитель, посредник)

В общем случае паттерн состоит из четырех основных элементов:

1) Имя. Сославшись на него, можно сразу описать проблему проектирования, ее решения и их последствия.

2) Задача. Описание того, когда следует применять паттерн. Может описываться конкретная проблема проектирования, например способ представления алгоритмов в виде объектов.

3) Решение. Описание элементов дизайна, отношений между ними, функций каждого элемента

4) Результаты – это следствия применения паттерна и разного рода компромиссы.

Удобнее классифицировать паттерны по двум критериям:

Первый критерий – цель – отражает назначение паттерна.

В связи с этим выделяют:

·порождающие паттерны- связаны с процессом создания объектов

·структурные паттерны- имеют отношение к композиции объектов и классов

· паттерны поведения- характеризуют то, как классы или объекты взаимодействуют между собой.

Второй критерий – уровень – говорит о том, к чему обычно применяется паттерн: к объектам или классам.

Паттерны уровня классов описывают отношения между классами и их подклассами.

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

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

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

В общем случае можно выделить два типа обязанностей:

1) знание (knowing);

2) действие (doing).

Обязанности, относящиеся к действиям объекта:

- выполнение некоторых  действий самим объектом, например создание экземпляра или выполнение вычислений;

- инициирование действий  других объектов;

- управление действиями  других объектов и их координирование.

Обязанности, относящиеся к знаниям объекта:

- наличие информации о  закрытых инкапсулированных данных;

- наличие информации о  связанных объектах;

- наличие информации о  следствиях или вычисляемых величинах.

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

Систематизация приемов программирования и принципов организации классов получила название шаблона (паттерна).

Шаблоны очень хорошо выражают преимущества объектно-ориентированного подхода, в частности, знаменитых «трех китов»: наследования, полиморфизма и инкапсуляции. При решении задач программирования с применением шаблонов следует придерживаться следующих рекомендаций: — изучение шаблонов приносит пользу вне зависимости от того, как часто они используются при программировании; — не следует торопиться с применением шаблонов при решении новой задачи; — шаблон в чистом (классическом, из учебника) виде, как правило, неприменим, применимы только вариации; — при применении шаблона следует начинать с его простейшей реализации, а уж затем вносить изменения по адаптации к конкретной ситуации; — если после применения шаблона код стал хуже, то шаблон лучше убрать.

«Низкоуровневые» шаблоны, учитывают специфику конкретного языка программирования, называются идиомами.

На наивысшем уровне существуют архитектурные шаблоны, они охватывают собой архитектуру всей программной системы.

Шаблон проектирования или паттерн(англ. Design pattern) – повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

Архитектура программного обеспечения — совокупность важнейших решений об организации программной системы.

Примеры архитектурных шаблонов:

· Многоуровневый шаблон (Layered pattern). Система разбивается на уровни, изображаются один над другим. Каждый уровень может вызывать только уровень на 1 ниже него. разработку каждого уровня можно вести  независимо. Недостатки - усложнение системы и снижение производительности.

·   Шаблон посредника (Broker pattern). В системе много модулей, сложное взаимодействие друг с другом. Вводится посредник, по которому модули общаются. Повышается совместимость модулей системы. Недостатки - наличие посредника: он понижает производительность, его недоступность может сделать недоступной всю систему, он может стать объектом атак и узким местом системы.

· Шаблон «Модель-Вид-Контроллер» (Model-View-Controller pattern). Интерфейс меняется, сохраняя корректное взаимодействие с данными (чтение, сохранение).

· Клиент-серверный шаблон (Client-Server pattern). Подход повышает масштабируемость и доступность системы.При его недоступности становится недоступна вся система.

10. Качество и эффективность ПО. Генерация кода на основе моделей. Конструирование высококачественного  кода. Тестирование, отладка, рефакторинг  и оптимизация кода.

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

План исполнения:

1. Определил границы системы 2. Определил структуру решения 3. Определил каркасы 4. Сопоставил функциональные требования с каркасами

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

Цель рефакторинга — сделать код программы более легким для понимания.

Причины, когда код нужно подвергнуть рефакторингу:

·Дублирование кода ·Длинный метод ·Большой класс ·Длинный список параметров и др.

Наиболее употребимые методы рефакторинга: ·Инкапсуляция поля ·Выделение класса ·Выделение интерфейса ·Выделение локальной переменной ·Выделение метода ·Встраивание

Ка́чество програ́ммного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям.

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

Некоторые из факторов качества:

· Понятность · Краткость · Портируемость · согласованность · Сопровождаемость · Тестируемость · Структурированность · Эффективность · Безопасность и др.

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

Методы тестирования: a) Черный ящик  b) Стеклянный (белый) ящик c) Тестирование моделей  d) Анализ программного кода (инспекции)

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

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

-воспроизведение дефекта -анализ дефекта -дизайн исправления дефекта -кодирование исправления дефекта -валидация исправления; -интеграция исправления в кодовую базу или целевую систему;  -дополнительные валидации после интеграции

11. Внедрение, сборка и поставка  проекта. Развертывание, технологии  и средства развертывания, наладки  и обслуживания проектов.

Внедрение ПО

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

·Экспресс-внедрение направлено на максимально «быстрый старт».

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

·Проектное внедрение. Использование Проектной технологии позволяет создать комплексную автоматизированную систему управления (АСУ) организацией для максимально эффективной поддержки бизнес-процессов Заказчика.

Сборка проекта

Данная работа состоит из следующих задач:

·Разработчик должен разработать план сборки для объединения программных модулей и компонентов в программный объект.

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

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

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

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

Поставка проекта.

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

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

Список работ. Данный процесс состоит из следующих работ:

1) подготовка;

2) подготовка ответа;

3) подготовка договора;

4) планирование;

5) выполнение и контроль;

6) проверка и оценка;

7) поставка и закрытие  договора.

12. Фазы, итерации и циклы разработки  программного кода. Рабочие процессы, модели и артефакты

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

·Начало - определение бизнес-целей проекта.

·Исследование - разработка плана и архитектуры проекта.

·Построение - постепенное создание системы (создание бета-версии).

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

Фазы начала и исследования охватывают проектные стадии жизненного цикла процесса разработки; фазы построения и внедрения относятся к производству.

Внутри каждой фазы происходит несколько итераций.

Итерация (iteration) (версии кода) представляет полный цикл разработки, от выработки требований во время анализа до реализации и тестирования. Итерация - это завершенный этап, в результате которого выпускается версия исполняемого продукта, реализующая часть запланированных функций. Затем эта версия от итерации к итерации наращивается до получения готовой системы.

Конечным результатом является выпуск готового продукта.

Прохождение через четыре основные фазы называется циклом разработки. Каждый цикл завершается генерацией версии системы.

Рациональный Унифицированный Процесс состоит из девяти рабочих процессов:

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

·требования - формализация образа системы.

·анализ и моделирование — предполагает перевод собранных требований в формализованную программную модель.

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

·тестирование.

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

·управление конфигурацией и изменениями — мощный слой административных действий, направленных на управление версиями продукта.

·управление проектом — предполагает набор административных действий управления проектом.

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

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

Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом.

Модель (model) - это упрощение реальности; она создается для лучшего понимания разрабатываемой системы.

13. Архитектура клиент-сервер. Многоуровневая  структура web-приложений.(java)

Клиент/серверная архитектура описывает распределенные системы, состоящие из отдельных клиента и сервера и соединяющей их сети. Простейшая форма системы клиент/сервер, называемая 2-уровневой архитектурой – это серверное приложение, к которому напрямую обращаются множество клиентов.

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

Для связи с клиентом сервер может использовать широкий диапазон протоколов и форматов данных.

На сегодняшний день примерами архитектурного стиля клиент/сервер могут служить Веб-приложения, выполняющиеся в Интернете или внутренних сетях организаций; настольные приложения, выполняющие доступ к сетевым сервисам данных; приложения, выполняющие доступ к удаленным хранилищам данных (такие как программы чтения электронной почты, FTP-клиенты и средства доступа к базам данных); инструменты и утилиты для работы с удаленными системами (такие как средства управления системой и средства мониторинга сети).

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

– Груз файловых операций ложится в основном на сервер, который мощнее компьютеров-клиентов и поэтому способен быстрее обслуживать запросы.

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

– Повышается уровень непротиворечивости данных и существенно повышается степень безопасности БД.

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

Общее представление о веб-приложении Java

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

Общие сведения о Java EE

Java EE (Enterprise Edition) представляет  собой широко используемую платформу, содержащую набор взаимосвязанных  технологий, которые существенно  сокращают стоимость и сложность  разработки, развертывания многоуровневых  серверных приложений, а также  управления ими. Платформа Java EE основана  на платформе Java SE и предоставляет  набор интерфейсов API (интерфейсов  разработки приложений) для разработки  и запуска портируемых, надежных, масштабируемых и безопасных  серверных приложений.

14. Структура  и размещение web-приложения. Этапы  разработки и развёртывания web-приложения. Роль web-сервера в развертывании  приложения на java.

Структура веб-приложения.

Логика веб-приложения распределена между сервером и клиентом, хранение и обработка данных осуществляется, преимущественно, на сервере, её представление в удобном для пользователя виде - в браузере. Обмен информацией происходит по сети.

Веб-приложения состоят как минимум из трёх основных компонентов.

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

Система управления базами данных, (СУБД) - программное обеспечение на сервере, занимающееся хранением данных и их выдачей в нужный момент.

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

Размещение web-приложения

Для того, чтобы веб-приложение стало доступно, его необходимо разместить в рамках веб-сервера Tomcat, Glassfish, JBoss, Sun и др. После этого приложение получит свой уникальный адрес в рамках протокола HTTP. Используя этот адрес, пользователь может обратиться к приложению.

Этапы разработки веб-приложения:

·определение целей и задач проекта;

·разработка структуры сайта;

·разработка дизайн-макетов;

·html-вёрстка;

·программирование и контроль качества;

·запуск и сопровождение, SEO-оптимизация.

Структура жизненного цикла базируется на трех группах процессов:

• основные процессы жизненного цикла программного обеспечения
• вспомогательные процессы
• организационные процессы

Роль web-сервера в развертывании приложения на java

Веб-сервер – это программное обеспечение, обеспечивающее доставку контента конечному пользователю по сети. Веб-сервер реализует серверную часть протокола HTTP.

Функции и особенности веб-серверов: передача контента пользователю; получение контента от пользователей; поддержка динамически генерируемых страниц; аутентификация и авторизация пользователей; ведение журнала обращений пользователей к ресурсам; поддержка HTTPS для защищённых соединений с клиентами.

Реализации веб-серверов:

·Apache Tomcat

·Glassfish

Apache Tomcat является одним  из наиболее популярных web-серверов.

Apache Tomcat состоит из следующих  компонентов:

1.      Web Connector Coyote

2.      Web Container Catalina

3.      Jasper Compiler

15. Структура архива WAR. Способы создания файла WAR. Описатель  развертывания web.xml: его назначение.

Что это: WebApplicationArchive (WAR) – это Web-приложение – совокупность сервлетов, HTML-страниц, классов и других ресурсов, которые могут связываться между собой и развертываться на нескольких серверах приложений стандарта Java EE.

Структура: WAR-файл состоит из следующих компонентов: сервлетов, которые находятся в каталоге WEB-INF, файлов JSP, библиотек тегов JSP, классов-утилит, статических страниц (HTML, файлы звука и изображения, и т.д.), аплетов на стороне клиента, бинов, классов бинов и аннотаций или дескрипторов развертывания (web.xml и sun-web.xml).

Как создать:

Когда мы добавляем первый Web-компонент в приложение J2EE, утилита deploytool автоматически создает новый WAR-файл, содержащий компонент. Следующий раздел объясняет, как добавить Web-компонент.

Создать WAR-архив можно:

·с помощью утилиты «паковщик», входящей в состав J2EE SDK.

·Выполнив в Apache Ant задачу «war».

·Выполнив в Apache Maven команду "mvn clean install".

·JAR-утилитой, входящей в J2SE. Если вы выстроите свои каталоги разработки приложения в структуру, требуемую форматом WAR, вам будет просто создать архивный файл Web-приложения в требуемом формате. Вы просто выполняете следующую команду в каталоге верхнего уровня приложения: jar cvf archiveName.war

Как развернуть: WAR нужно положить в папку webapps в томкате и открыть localhost.

Описатель развертывания: в каталоге «WEB-INF» находится документ «web.xml», это и есть дескриптор развёртывания. В нем содержится информация, необходимая для развертывания веб-приложения, там описываются все сервлеты и другие свойства Web-приложения. Если приложение содержит только JSP-файлы, этот файл не строго обязателен.

Директория /WEB-INF/classes находится в classpath ClassLoader. Эти java-файлы с расширением .class будут загружены, когда веб-приложение загрузится и начнет выполняться. Любые файлы JAR, находящиеся в каталоге /WEB-INF/lib, также будут помещены в classpath.

16. Порядок компоновки веб-приложения. Технологии сборки и развёртывания  веб-приложения. Файл сборки build.xml.  Утилита Apache Ant и её назначение

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

Apache Ant – средство автоматизации, созданное на базе Java и XML, как программное обеспечение (утилита Ant) с открытым исходным кодом, которое представляет собой инструмент, позволяющий автоматизировать процесс компоновки java-проекта. Сюда относится компиляция java-файлов, создание java-библиотек (jar-файлы) и специальных файлов для размещения приложения на сервере (war-файлы). Управление процессом сборки происходит посредством XML-сценария, также называемого Build-файлом. Этот файл содержит определение проекта, состоящего из отдельных целей (Targets).

Типичными примерами целей являются clean (удаление промежуточных файлов), compile (компиляция всех классов), deploy (развёртывание приложения на сервере). Конкретный набор целей и их взаимосвязи зависят от специфики проекта.

Ant позволяет определять  собственные типы заданий путём  создания Java-классов, реализующих определённые интерфейсы.

Ant'у необходима помощь  в виде build файла. Build файл показывает Ant'у что надо делать, чтобы превратить то что есть (как правило, исходный код) в то что вы хотите. Build файл похож на детальный план - он говорит вам как собрать из частей единое целое.

Build файл содержит правила, которые указывают Ant'у делать  вещи наподобие таких:

• В соответствии с тем что мне нужно, скопируй Russell.jar в каталог релиза...
• кстати, сначала ты должен собрать Russell.jar;
• кстати, для того, чтобы собрать Russell.jar, примени команду jar к *.class файлам
• кстати, тебе нужно скомпилировать class файлы, если ты этого еще не сделал.
• Для того, чтобы сделать *.class файлы, запусти компилятор Java для *.java файлов.

Порядок компоновки web-приложения описывается в файле сборки, который содержит входную информацию для утилиты Ant. Файл сборки – это xml-файл, описывающий с помощью xml-элементов и атрибутов последовательность действий, которые должна исполнить 19 утилита Ant. По умолчанию имя файла сборки – build.xml. Если в параметрах вызова команды ant не указан путь, то предполагается, что он находится в текущей директории.

17. Понятие сервлета. Жизненный цикл  сервлета: обработка событий, связанных  с жизненным циклом; обработка  ошибок.

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

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

1. В случае отсутствия  сервлета в контейнере.

1. Класс сервлета загружается  контейнером.

2. Контейнер создает экземпляр  класса сервлета.

3. Контейнер вызывает  метод init().

 Сервлеты выполняются  на платформе Web-сервера как часть  того же процесса, что и сам Web-сервер. Web-сервер взаимодействует  с сервлетом через простой  интерфейс: javax.servlet.Servlet.

Интерфейс javax.servlet.Servlet состоит из трех главных методов:

·init()

·service()

·destroy()

и двух вспомогательных методов:

·getServletConfig()

·getServletInfo()

Обработка событий жизненного цикла сервлета

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

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

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

Обработка ошибок

При выполнении сервлета может происходить любое количество исключений. Web-контейнер, когда произойдет исключение, будет генерировать страницу по умолчанию, содержащую сообщение A Servlet Exception Has Occurred, но также можно задать, чтобы контейнер возвращал заданную страницу ошибки для данного исключения.

18. Интерфейс ServletContext: назначение и  использование. Сессия: доступ, связывание  с объектами, управление. Методы  GetSession(), SetAttribute(), getAttribute()

Интерфейс javax.servlet.ServletContext предоставляет доступ сервлету к параметрам веб приложения. Объект ServletContext является уникальным и доступен всем сервлетам веб приложения. Получить ссылку на объект ServletContext можно вызовом метода getServletContext().

 Экземпляры классов  ServletContext,  Java Servlets называются контейнерами с ограниченным сроком жизни (scoped containers). При использовании, ServletContext данные существуют на протяжении всего жизненного цикла приложения.

Методы:

• String getMimeType(String filename) – определение MIME-типа файла или документа.
• String getRealPath(String filename) – определение истинного маршрута файла относительно каталога, в котором сервер хранит документы;
• String getServerInfo() – предоставляет информацию о самом сервере.

Сеанс (сессия) – соединение между клиентом и сервером, устанавливаемое на определенное время, за которое клиент может отправить на сервер сколько угодно запросов. Сеанс устанавливается непосредственно между клиентом и Web- сервером. Каждый клиент устанавливает с сервером свой собственный сеанс.

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

· поддержка распределенной сессии;

 · обеспечение безопасности;

 · проблема инвалидации  сессии (expiration), предупреждение пользователя  об уничтожении сессии и возможность  ее продления (watchdog).e.

Чтобы открыть новый сеанс, используется метод getSession() интерфейса HttpServletRequest. Метод извлекает из переданного в сервлет запроса объект сессии класса HttpSession, соответствующий данному пользователю. Сессия содержит информацию о дате и времени создания последнего обращения к сессии, которая может быть извлечена с помощью методов getCreationTime() и getLastAccessedTime().

Чтобы сохранить значения переменной в текущем сеансе, используется метод setAttribute() класса HttpSession. getAttribute() - получает значение атрибута по имени, removeAttribute() - удаляет атрибут из контекста.

19. Требования к современному веб-проложению. Понятие страницы JSP. Жизненный цикл JSP-страницы. Создание статического  контента. Создание динамического  контента.

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

Формально каждое web-приложение можно разбить на 3 взаимно независимые части.

1. Модуль, который исполняется WEB-браузером. Это приложение может быть написано на любом языке, который поддерживает браузер. Чаще всего используется язык JavaScript.

2. Модуль, исполняемый на серверной стороне  под управлением web-сервера. Это приложение может быть написано на любом языке, интерпретацию которого поддерживает выбранный Вами web-сервер.

3. База  данных. БД выбирается основываясь на целях и области решаемых задач.

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

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

ЖЦ:

1. Если экземпляр  сервлета страницы JSP не существует, контейнер:

- загружает класс  сервлета страницы JSP;

- создает экземпляр  класса сервлета;

- инициализирует  экземпляр сервлета вызовом метода jspInit.

2. Вызывает метод _jspService, передавая ему объекты  запроса и отклика.

Если контейнеру нужно удалить сервлет страницы JSP, он вызывает метод jspDestroy.

 Статические сайты, содержащие статические HTML или XHTML страницы. Статические веб-страницы - это статические файлы (набор текста, таблиц, рисунков и т.д.), которые создается с помощью языка разметки HTML (имеют расширение .html или .htm) и хранятся в готовом виде в файловой системе сервера.

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

20.     Извлечение полей и значений  в JSP. Директивы, объявления, выражения, скриплеты.

Выражения:

Выражения JSP применяются для того чтобы вставить значения Java непосредственно в вывод. Для этого используется следующая форма:

<%= Выражение на Java %>

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

Скриплеты JSP

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

<% Код на Java %>

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

Объявления JSP

Объявления JSP позволят вам задать методы или поля, для вставки в тело класса сервлета (вне метода service, обрабатывающего запрос). Они имеют следующую форму:

<%! Код на Java %>

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

Директивы JSP

Директивы JSP воздействуют на всю структуру класса сервлета. Обычно они имеют следующую форму:

<%@ директива атрибут="значение" %>

Существуют два основных типа директив: page, которая позволяет вам совершать такие операции, как импорт классов, изменение суперкласса сервлета, и т.п.; и include, которая дает вам возможность вставить файл в класс сервлета при трансляции JSP файла в сервлет.

21. Стандартные элементы action в JSP. Передача  управления другому веб-компоненту.

JSP – технология, позволяющая веб-разработчикам  создавать содержимое, которое имеет  как статические, так и динамические  компоненты. В дополнение к классам  и интерфейсам для программирования  сервлетов (пакеты javax.servlet и javax.servlet.http), в пакетах javax.servlet.jsp и javax.servlet.jsp.target содержатся классы и интерфейсы, относящиеся к программированию Java Server Pages.

Тег — именованная метка; более правильное название — дескриптор.

Стандартные элементы action выглядят как обычные тэги, название которых начинается с сочетания символов jsp:, например <jsp:include ...>. Согласно терминологии XML, это означает, что стандартные элементы action в технологии JSP принадлежат пространству имен jsp.

jsp:useBean позволяет использовать на JSP странице объекты, соответствующие компонентам JavaBean. Элемент <jsp:useBean> содержит параметр, который связывает с компонентом некий уникальный идентификатор. Последний затем будет использоваться при обращениях к этому объекту:

<jsp:useBean id="customer" class="com.myco.Customer" />

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

<jsp:include page="/inc/menu.jsp" />

jsp:forward данный элемент позволяет переадресовать дальнейшее формирование динамической страницы на другую JSP страницу, сервлет или использовать для завершения заранее приготовленный текст.

<jsp:forward page="/inc/copyright.jsp" />

• Если вы захотите передать процесс управления от одной страницы другой, вы можете либо переслать его другой странице (<jsp:useBean> и <jsp:setProperty>) , либо переадресовать новой странице (с помощью метода sendRedirect() объекта, выступающего в качестве имплицитного ответа).

22. Особенности спецификаций в Java Platform, Enterprise Edition и возможности API в Java EE. Концепция  распределенной и удаленной обработки  данных.

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

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

Платформа Java EE основана на платформе Java SE и предоставляет набор интерфейсов API (интерфейсов разработки приложений) для разработки и запуска портируемых, надежных, масштабируемых и безопасных серверных приложений.

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

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

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

При этом можно выделить следующие формы взаимодействия между компьютерами:

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

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

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

4) взаимодействие компьютер – компьютер предусматривает обмен сообщениями между компьютерами сети в диалоговом режиме.

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

23. Архитектура и уровни распределенных  систем. Модели распределённых вычислений. Многозвенные распределительные  системы. Компонентные системы lava EE. Базисные архитектуры.

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

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

Достоинства:

1) сервер БД – может  быть изготовлен по спец. Заказу  и приспособлен для работы  с СУБД, чтобы обеспечить лучшую  производительность

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

Архитектуры:

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

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

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

· представление данных (пользовательский уровень).

· обработка данных (промежуточный уровень, middleware).

· хранение данных (уровень данных).

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

24. Архитектура RMI: интерфейсы и их  реализация, стабы, скелетоны, транспортный  уровень. Метод организации вызова  удаленных процедур (RPC –Remote procedure call).

RMI позволяет клиентским и серверным приложениям через сеть вызывать методы клиентов/серверов, выполняющихся в Java Virtual Machine. Она обладает рядом уникальных свойств, таких как распределенное, автоматическое управление объектами и возможность пересылать сами объекты от машине к машине.

Client Stub (переходник для клиента) и Server Stub (переходник для сервера) порождены от общего интерфейса, но различие между ними в том, что client stub служит просто для подсоединения к RMI Registry, а server stub используется для связи непосредственно с функциями сервера.

Основное преимущество RMI заключается в том, что он предоставляет программируемый интерфейс более высокого уровня, который позволяет передавать ссылку на удаленный объект в качестве аргумента или возвращать ее в качестве результата. RMI требует, чтобы на обоих концах соединения выполнялись Java-программы. Сетевое соединение достигается с использованием TCP/IP-протокола.

Интерфейсы в RMI

Архитектура RMI основана на одном важном принципе: RMI дает возможность разделить и выполнить на разных JVM код, определяющий поведение, и код, реализующий поведение.

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

Реализация RMI по существу состоит из трех абстрактных слоев.

Первый — слой Stub и Skeleton классов, реализация которых скрыта от глаз разработчика. Этот слой занимается перехватом вызовов методов заданного интерфейса, которые делает клиент, и переадресацией их удаленному RMI-сервису. Следующий слой — Remote Reference Layer. Этот слой "знает", как нужно интерпретировать и управлять ссылками от клиента к объектам удаленного сервиса. И последний слой — транспортный. Этот слой работает с TCP/IP-соединениями между машинами, находящимися в сети. Он предоставляет базовые возможности установки соединений, а также некоторые стратегии обхода firewall-систем (брандмауэров).

Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. То есть, клиентское приложение обращается к процедурам, хранящимся на сервере.

Характерными чертами RPC являются:

·асимметричность, то есть одна из взаимодействующих сторон является инициатором;

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

25. Инсталляция программных компонентов  в RMI, автоматическая загрузка классов, сериализация, параметризация, маршализация, демаршализация.

RMI позволяет клиентским и серверным приложениям через сеть вызывать методы клиентов/серверов, выполняющихся в Java Virtual Machine.

Перед непосредственным вызовом на клиентской и серверной стороне должны быть созданы специальные структуры (процедуры, файлы) - это так называемые клиентский стаб (stub) и серверный скелетон (skeleton), которые необходимы для корректной работы RPC.

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

1.Процедура клиента вызывает  стаб как обычную процедуру. Стаб  упаковывает параметры (маршализация, marshaling).

2.Стаб обращается к  ядру ОС.

3.Ядро посылает сообщение  на удаленную машину (ядру удаленного  ПК).

4.Передача полученного  сообщения скелетону серверного  процесса.

5.Распаковка параметров (демаршализация, unmarshaling). Вызов требуемой  процедуры.

6.Процедура на сервере  выполняется. Возвращает результаты  скелетону.

7.Скелетон упаковывает  результат.

8.Передача результата  ядру.

9.Ядро сервера передает  сообщение по сети ядру клиента.

10.Ядро клиента обращается  к стабу. Стаб распаковывает полученный  результат.

11.Передача от стаба  клиентскому процессу.

Сериализация объекта это способность объекта сохранять полную копию его и любых других объектов на которые он ссылается, используя поток вывода (например, во внешний файл). Таким образом, объект может быть воссоздан из сериализованной(сохраненной) копии немного позже, когда это потребуется. Главным образом это происходит автоматически благодаря классам ObjectInputStream и ObjectOutputStream.

Параметризация — моделирование с использованием параметров элементов модели и соотношений между этими параметрами.

Маршализация- механизм преобразования данных из java-объектов в конкретное хранилище.

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

26. Концепция интеграции различных  изолированных объектных систем. Стандарты группы OMG. Архитектурные  решения и механизмы стандарта CORBA. Поддержка и реализация механизмов CORBA на платформе JAVA. GIOP Язык IDL: синтаксис, интерфейсы, ограничения, компиляторы IDL.

OMG (Object Managment Group). OMG насчитывает более 700 членов (в OMG входят практически все крупнейшие производители ПО, за исключением Microsoft).

Задачей OMG является определение набора спецификаций, позволяющих строить информационные системы. Спецификация OMG — The Common Object Request Broker Architecture (CORBA) является индустриальным стандартом, описывающим высокоуровневые средства поддерживания взаимодействия объектов в распределенных средах.

CORBA специфицирует инфраструктуру взаимодействия компонент (объектов) на представительском уровне и уровне приложений. Она позволяет рассматривать все приложения в распределенной системе как объекты. Причем объекты могут одновременно играть роль и клиента, и сервера: роль клиента, если объект является инициатором вызова метода у другого объекта; роль сервера, если другой объект вызывает на нем какой-нибудь метод. Объекты-серверы обычно называют ``реализацией объектов''.

Dynamic Invocation Interface (DII): позволяет клиенту находить сервера и вызывать их методы во время работы системы. IDL Stubs: определяет, каким образом клиент производит вызов сервера. ORB Interface: общие как для клиента, так и для сервера сервисы. IDL Skeleton: обеспечивает статические интерфейсы для объектов определенного типа. Dynamic Skeleton Inerface: общие интерфейсы для объектов, независимо от их типа, которые не были определены в IDL Skeleton. Object Adapter:осуществляет коммуникационное взаимодействие между объектом и ORB.

Язык OMG IDL (Interface Definition Language — Язык Описания Интерфейсов) представляет собой технологически независимый синтаксис для описания интерфейсов объектов. IDL является чисто декларативным языком, то есть он не содержит никакой реализации. IDL-спецификации могут быть откомпилированы (отображены) в заголовочные файлы и специальные прототипы серверов, которые могут использоваться непосредственно программистом. То есть IDL-определенные методы могут быть написаны, а затем выполнены, на любом языке, для которого существует отображение из IDL. К таким языкам относятся C, C++, SmallTalk, Java и Ada.

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

27. Язык описания интерфейсов IDL: синтаксис, интерфейсы, ограничения, компиляторы IDL. Стандартизация для различных  языков программирования

Язык OMG IDL (Interface Definition Language — Язык Описания Интерфейсов) представляет собой технологически независимый синтаксис для описания интерфейсов объектов. OMG IDL позволяет описывать интерфейсы, имеющие различные методы и атрибуты.

Общий синтаксис:

Значительное влияние на разработку синтаксиса языка OMG IDL оказал язык C++. В IDL используются лексические соглашения, принятые в C++. Он полностью поддерживает средства препроцессорной технологии, предусмотренные в стандарте ANSI C++. Грамматику OMG IDL можно рассматривать как подмножество грамматики языка ANSI C++, расширенное дополнительными конструкциями, которые необходимы для поддержки механизма вызова операций.

Для описания синтаксиса языка в спецификациях стандарта CORBA используется нотация, аналогичная EBNF (Extended Backus-Naur Format - Расширенный формат Бэкуса-Наура).

Интерфейсы:

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

Репозитарий Интерфейсов (Interface Repositary), содержащий определения интерфейсов на IDL, позволяет видеть интерфейсы доступных серверов в сети и программировать их использование в программах-клиентах.

Ограничения:

В отличие от C++, OMG IDL является декларативным языком. В нем нет средств описания алгоритмов и переменных. Так, в OMG IDL обязательно:

·        Должен специфицироваться тип возвращаемого функцией значения.

·        Для каждого формального параметра в объявлении операции должно специфицироваться имя.

·        Исключаются спецификации типа "char" с ключевыми словами "signed" или "unsigned" и т.д.

 Компиляторы:

1)  Компилятор IDL к Java – idlj из JDK 1.2

2) IDL2JAVA из набора Inprise VisiBroker

3) IDL2PAS

4)  MICO

 Стандартизация:

Спецификации могут быть откомпилированы (отображены) в заголовочные файлы и специальные прототипы серверов, которые могут использоваться непосредственно программистом. То есть IDL-определенные методы могут быть написаны, а затем выполнены, на любом языке, для которого существует отображение из IDL. К таким языкам относятся C, C++, SmallTalk, Java и Ada.

28 Унифицированные  средства, службы, механизмы и языки  программирования в технологии CORBA. Брокер объектных запросов и  его основные задачи.

CORBA специфицирует инфраструктуру взаимодействия компонент (объектов) на представительском уровне и уровне приложений. Она позволяет рассматривать все приложения в распределенной системе как объекты. Причем объекты могут одновременно играть роль и клиента, и сервера: роль клиента, если объект является инициатором вызова метода у другого объекта; роль сервера, если другой объект вызывает на нем какой-нибудь метод. Объекты-серверы обычно называют ``реализацией объектов''.

Сервант — серверная программа, написанная на каком-либо из языков программирования и выполняющая CORBA-объект.

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

Инкарнация — связывание серванта с CORBA-объектом для обработки клиентского запроса.

CORBA состоит из следующих компонентов:

Брокер объектных запросов (ObjectRequestBroker), который дает возможность объектам прозрачно создавать запросы и получать ответы в распределенной среде. Он является основой для построения приложений из распределенных объектов, для способности к взаимодействию (interoperability) между приложениями в гетеро - и гомогенной средах.

Сервисы объектов (ObjectServices), коллекция сервисов (интерфейсы и объекты), которые поддерживают основные функции для использования и реализации объектов.

Общие средства (CommonFacilities), коллекция сервисов.

Объекты приложения (ApplicationObject) являются продуктами одной группы разработчиков, которая контролирует свои интерфейсы.

При определении конкретной архитектуры Брокер Объектных Запросов вовсе необязательно должен быть реализован как один компонент, но каждая реализация должна реализовывать три категории операций:

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

Ядро Брокера Объектных Запросов обеспечивает основные механизмы для манипуляций объектами и выполнения запросов.

29. Компонентная  модель CORBA 3 (CCM). Сервисы имен. Сервант, адаптеры, POA.

Компонентная модель CORBA (CCM) — недавнее дополнение к семейству определений CORBA.

CCM была введена  начиная с CORBA 3.0 и описывает стандартный  каркас приложения для компонент CORBA.

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

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

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

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

Получение ссылки на объект по переданной строке (имени) называется разрешением имени (resolving the name).

Сервант - серверная программа, написанная на каком-либо из языков программирования и выполняющая CORBA-объект. Это может быть набор функций, представляющих состояние объекта (на Си или Коболе) или реализации определенных классов серверного приложения (на C++ или Java). Сервант написан на том же программном языке, что и приложение, и является программной реализацией объекта CORBA.

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

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

В CORBA-приложениях используется древовидная иерархия объектных адаптеров. В корне ее находится так называемый Root POA – объектный адаптер по умолчанию.

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

30. Понятие, назначение EJB-технологии. Создание  корпоративных приложений на  основе распределенных компонентных  технологий 

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

Enterprise bean(«корпоративный компонент») – это написанный на языке программирования Java компонент, исполняемой на стороне сервера, который инкапсулирует бизнес-логику приложения.

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

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

· поддержка распределённых транзакций

· поддержка параллельного изменения данных и многопоточность

· безопасность и ограничение доступа к данным

· удалённый доступ

Каждый EJB-компонент является набором Java-классов со строго регламентированными правилами именования методов. Бывают трёх основных типов:

·         объектные (Entity Bean)

·         сессионные (Session Beans)

·         управляемые сообщениями (Message Driven Beans)

Создание корпоративного компонента (enterprise bean)

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

Кодирование корпоративного компонента

Корпоративный компонент состоит из следующих частей:

• Удаленный интерфейс
• "Домашний" интерфейс
• Класс корпоративного компонента

Компилирование файлов с исходными кодами

Набирается команда «ant converter»

По этой команде компилируются исходные файлы корпоративного компонента и клиентского J2EE-приложения.

Пакетирование корпоративного компонента

Для пакетирования корпоративного компонента используется мастер New Enterprise Bean утилиты deploytool.

31.Классы интерфейсы и методы  обеспечения работы бинов в EJB, жизненный цикл бина и методы  его обеспечения. Удаленный и  локальный интерфейсы, соглашения  имен. Объектные компоненты.

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

Для реализации объектного или сеансового компонента необходимо определить:

• интерфейсы компонента
• класс компонента и
• первичный ключ (только для объектных компонентов).

Жизненный цикл Entity-бина состоит из трех состояний:

а) Бин не существует;

б) Бин находится в "обобщенном" (pooled) режиме, куда сервер приложений по спецификации переводит набор бинов, задавая им метод setEntityContext(). Таким образом, в этом состоянии бин получил кое-какие признаки своего класса, но ещё не идентифицирован с определенным полем в СУБД;

в) Бин находится в "готовом" (ready) режиме, он идентифицирован с конкретными данными в базе данных.

Жизненный цикл Statefull Session-бина состоит из:

а) Бин не существует;

б) Бин готов к работе;

в) Пассивный режим.

Жизненный цикл Stateless Session-бина состоит из:

а) Бин не существует;

б) Бин готов к работе.

 Удаленный  интерфейс (Remote Interface) определяет прикладные методы компонента, доступные из приложений, внешних по отношению к контейнеру EJB, то есть прикладные методы, которые компонент представляет внешним приложениям. Удаленный интерфейс расширяет (extends) интерфейс javax.ejb.EJBObject.Внешние по отношению к EJB приложения вызывают методы удаленного интерфейса, а получают эти методы они при помощи домашнего интерфейса (Home Interface).

Локальный интерфейс (Local Interface) определяет прикладные методы EJB, которые могут использоваться другими компонентами, размещенными в том же контейнере EJB,но не внешними по отношению к контейнеру EJB приложениями. Локальный интерфейс расширяет (extends) интерфейс javax.ejb.EJBLocalObject. Внешние по отношению к EJB компоненты, находящиеся в том же самом контейнере, работают с методами локального интерфейса, а получают эти методы они при помощи локального домашнего интерфейса (Local Home Interface)

Entity bean представляет собой компоненту, работающую с постоянной (persistent) информацией. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям.

Объектные компоненты являются серверными компонентами, основанными на RMI,к которым можно получить доступ при помощи распределенных объектных протоколов. Компоненты, управляемые сообщениями, появившиеся в EJB 2.0 - это асинхронные серверные компоненты, которые отвечают на асинхронные сообщения JMS и других протоколов.

32. Сессионные компоненты в EJB. Виды  сессионных бинов, сравнительная  характеристика, использование. Особенности stateless и stateful бинов

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

Enterprise bean(«корпоративный компонент») – это написанный на языке программирования Java компонент, исполняемой на стороне сервера, который инкапсулирует бизнес-логику приложения.

Именно бины, а не клиентские приложения, содержат логику приложения.

JavaBean -  это классический  самодостаточный объект, который, будучи  написан один раз, может быть  многократно использован при  построении новых апплетов, сервлетов, полноценных приложений, а также  других компонентов Java Bean.

Типы компонентов enterprise beans:

1) Сессионный. Исполняет задачи клиента, может быть реализован как web-сервис.

2) Управляемый событиями– действует как слушатель конкретного типа сообщений.

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

Режимы состояний бина:

1) Сохраняющие состояние (stateful)

2) Несохраняющие состояние (stateless)

В сессионном бине, сохраняющем свое состояние (stateful session bean), переменные представляют состояние уникальной сессии между клиентом и бином. Т.к. клиент взаимодействует («разговаривает») с бином, то такое состояние часто называется диалоговым (conversational state).

Состояние остается сохраненным в течение сессии клиент-бин. Если клиент удаляет бин или завершает его работу, то сессия завершается и состояние теряется.

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

33. Методы жизненного цикла EJB. Взаимодействие  клиента с компонентами EJB. POJO (Plain Old Java Objects) и POЛ(Plain Old Java Interfaces) . Жизненный цикл компонента. Получение доступа к компоненту (через аннотации, через контекст java.comp/eny jndi.

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

 2 события жизненного цикла, которые мы можем перехватить: создание и удаление бина. Метод, который будет вызываться сразу после создании бина помечается аннотацией @PostConstruct, а перед его удалением — @PreDestroy. Stateful бины обладают помимо рассмотренных выше еще 2 событиями:

1) При активации @PostActivate;

2) При деактивации @PrePassivate.

Стандартный сценарий взаимодействия клиента с компонентами EJB:

1: Клиент ищет Home-интерфейс  нужного ему компонента по  его имени через сервис имен JNDI.

2: Клиент, через найденный Home-интерфейс, вызывает функцию создания  экземпляра компонента на стороне  сервера.

2.1: Сервер создает этот  экземпляр.

3: Клиент вызывает бизнес-метод  на созданном компоненте через  его Remote-интерфейс этого компонента.

3.1: Сервер вызывает бизнес-метод  на конкретном экземпляре компонента.

POJO (Plain Old Java Object) —простой Java-объект, не унаследованный от какого-то специфического объекта и не реализующий никаких служебных интерфейсов сверх тех, которые нужны для бизнес-модели.

Жизненный цикл компонентов. Существует два различных типа ``бинов'': session и entity. Отличаются они жизненнным циклом компонента. Session bean представляет собой EJB-компоненту, связанную с одним клиентом. ``Бины'' этого типа, как правило, имеют ограниченный срок жизни (хотя это и не обязательно), и редко участвуют в транзакциях. В частности, они обычно не восстанавливаются после сбоя сервера. Entity bean - компонента, работающую с постоянной (persistent) информацией, хранящейся, например, в базе данных. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entity beans живут постоянно, ``выживая'', тем самым, после сбоев.

 Доступ к файлу возможен через контекст java.comp/eny jndi, а также используются аннотации:

@EJB — помечается bean, который мы собираемся использовать.

@Stateless — говорит контейнеру, что класс будет stateless session bean. Для него контейнер обеспечит безопасность потоков и менеджмент транзакций.

@Local — относится к интерфейсу и говорит, что bean реализующий интерфейс доступен локально.

@Remote — относится к интерфейсу и говорит, что bean доступен через RMI (Remote Method Invocation).

@Stateful — говорит контейнеру, что класс будет stateful session bean.

@Remove — метод, помеченный как Remove говорит контейнеру, что после его исполнения нет больше смысла хранить bean, т.е. его состояние сбрасывается. Это бывает критично для производительности.

@WebService — говорит, что интерфейс или класс будет представлять web-сервис.

34. Сущностные компоненты в EJB: понятие, основные механизмы организации  взаимодействия с БД. Методы организации  работы с сущностными компонентами  в EJB.

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

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

Etities — это сущности каких-то объектов и в EJB оно является хранилищем данных на период жизненного цикла Entity.

Entities является свое-родным  отображением таблиц в БД.

Для работы с entity был создан JPA (Java Persistence API).

JPA определяет  стандарт для:

1) конфигурации маппинга  сущностей приложения и их  отображения в таблицах БД;

2) EntityManager API — позволяет  выполнять CRUD (create, read, update, delete) операции  над сущностями;

3) Java Persistence Query Language (JPQL) —  для поиска и получения данных  приложения;

 Entity bean, представляет собой компоненту, работающую с постоянной (persistent) информацией, хранящейся, например, в базе данных. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entity beans живут постоянно, ``выживая'', тем самым, после сбоев сервера (когда сервер восстанавливается после сбоя, он может восстановить ``бин'' из базы данных).

Клиент создает на EJB-сервере объекты и работает с ними так же, как если бы это были локальные объекты.

Каждый экземпляр ``бина'' имеет свой уникальный идентификатор. Для entity объектов уникальный идентификатор, как правило, совпадает с уникального идентификатора данных, которые он представляет. То есть в данном случае существует нечто вроде первичного ключа для всех entity beans. Идентификатор же session beans может быть практически любым -- например он может состоять из имени сервера и порта удаленного соединения, а может создаваться случайным образом.

Каждый компонент EJB состоит из удаленного интерфейса, собственного интерфейса и реализации EJB-компонента.

35. Разработка приложений на основе  МОМ (Message-Oriented Middleware). Обработка асинхронных  сообщений в JMS. Интерфейсы, методы, метаданные. 

Промежуточное программное обеспечение, ориентированное на обработку сообщений (англ. Message-Oriented Middleware, MOM.), или сервисы обработки сообщений.

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

Сервисы middleware представляют приложениям разнобразные функции API обеспечивают:

-прозрачный доступ к  другим сетевым сервисам и  приложениям;

-независимость от других  сетевых сервисов;

-высокую надежность и  постоянную готовность.

JMS, Java Message Service - это Java API для  работы с Message-Oriented Middleware, разработанная, чтобы предоставить разработчикам  создавать гибкие и слабосвязанные  приложения с использованием  асинхронного обмена данными  между приложениями (клиентами/серверами) через посредника.

JMS поддерживает две модели  обмена сообщениями: point-to-point(точка - точка) и publish-subscribe(издатель-подписчик).

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

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

Основными достоинствами такого способа взаимодействия являются:

простота использования API;

гарантированная доставка сообщений;

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

Структура JMS сообщения

Сообщение состоит из заголовка, поля свойств и тела.

Заголовок хранит мета информацию сообщения, заполняемую автоматически.

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

Тело содержит полезную нагрузку сообщения.

Важно понимать, что JMS обеспечивает доставку сообщений только целевым объектам, а не «истинным» потребителям.

Важнейшим понятием JMS является сессия (session). Проще всего трактовать сессию как контекст потока, в котором выполняется передача сообщений. Фабрикой сессий является соединение (connection).

36. Основы и концепции JMS (Java Message Service). Построение JMS приложения, основные модели и механизмы.

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

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

JMS определяет две модели обмена сообщениями:

1. point-to-point. Программный модуль-отправитель передает сообщение, после чего оно попадает в очередь. С одной очередью могут работать несколько отправителей. Сообщение доставляется программному модулю, который зарегистрирован как получатель, или адресат. Если получатель не зарегистрирован, сообщение будет сохранено в очереди.

2. Подписчик (subscriber) подписывается на определённую тему (topic). Издатель (publisher) передает своё сообщение. Его получают все подписчики этой темы.

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

37. Основные объекты JMS. Порядок действий  на клиентской стороне при  отправке сообщения. JMS Client. Объекты Connection и ConnectionFactory.

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

1) ConnectionFactory - Объект, создающий Connection. Администратор MOM создает данный объект и связывает его с деревом JNDI, так что JMS может получить доступ к ConnectionFactory, используя стандартный JNDI lookup – механизм.

2) Connection - Соединение с сервером JMS. Создает объект Session.

3) Session – объект, используемый клиентами для посылки и принятия сообщений. Создает объект Destination.

4) Destination - Объект, хранящий адреса сообщений (имя топика или очереди). С его помощью создаются объекты, отвечающие за отсылку сообщений на конкретно указанный адресат и их получения оттуда.

5) MessageProducer - Объект для отправки сообщений.

6) MessageConsumer - Объект для получения сообщений.

 Порядок действий при отправке сообщений:

·      Используем JMS и JNDI пакеты, инициализируем контекст сервиса JNDI

·      Достаем ссылку на ConnectionFactory, опираясь на заданное нами имя при создании (развертывании ресурса)

·      Создадим Connection абстракция реального соединения

·      Создадим Session

·      Находим Destination, либо создаем ее

·      Создадим простейшее текстовое сообщение

·      Создадим MessageProducer

·      Активизация связи Connection

·      Посылаем сообщение

JMS Client  - Прикладные программы Java, использующие JMS. Приложение JMS (JMS application) – это прикладная система, состоящая из нескольких JMS клиентов, и как правило одного JMS-провайдера JMS-клиент, посылающий сообщение, называется поставщиком (producer). JMS-клиент, принимающий сообщение, называется потребителем (consumer). Один и тот же JMS клиент может быть одновременно и поставщиком и потребителем в разных актах взаимодействия.

Любой компонент, использующий JMS, должен создать соединение с JMS провайдером – собственно системой, обеспечивающей всю функциональности управления сообщениями. Для этого используется специальная фабрика объектов - ConnectionFactory. ConnectionFactory на самом деле является интерфейсом, от которого наследуют QueueConnectionFactory, TopicConnectionFactory ,XAQueueConnectionFactoy и XATopicConnectionFactory. Таким образом, мы будем иметь дело с реализацией одного из этих интерфейсов. Для того чтобы получить доступ к ConnectionFactory, программа должна извлечь соответствующую ссылку из JNDI.

38. Роль сессии в контексте  соединения JMS. Создание провайдера(продюсера).

Java Message Service (JMS) — стандарт промежуточного ПО для рассылки сообщений, позволяющий приложениям, выполненным на платформе Java EE, создавать, посылать, получать и читать сообщения. Часть Java Platform, Enterprise Edition.

Session – обьект, создаваемый JMS Connection и используемый клиентами для посылки и принятия сообщений. В случае point-to-point(если на сервере destination имеет тип queue, то сообщение, которое отправил producer, получает единственный consumer) используется javax.jms.QueueSession, в случае pub-sub – javax.jms.TopicSession(если на сервере destination имеет тип topic, то одно сообщение может быть прочитано неограниченным количеством consumer, подписанных на этот на этот destination). Фактически, это главная "рабочая лошадка" JMS.  

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

 Провайдер JMS — это реализация, удовлетворяющая спецификации JMS. Провайдер JMS отвечает за прием, хранение и доставку сообщений.

39. Получение jms сообщения в режиме  извлечения. Создание получателя  сообщений. MessageConsumer.

JMS-сеанс также функционирует  как фабрика для получателей JMS-сообщений. JMSклиент использует получателя  сообщений для получения сообщений  из пункта назначения в провайдере JMS. Получатель JMS-сообщений не поддерживает  параллельное использование.

 «Получатели сообщений»  могут работать в режиме извлечения (pull) и режиме приема (push). В спецификации JMS определяются получатели сообщений  для обоих режимов.

Режим извлечения

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

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

Пример 8.6. Получение JMS-сообщения в режиме извлечения

// Создание получателя сообщений

MessageConsumer msgConsumer = session.createConsumer(destination);

// Запуск соединения

conn1.start();

// Попытка получить сообщение

Message msg = msgConsumer.receiveNoWait();

// Проверка наличия текстовых  сообщений if (msg instanceof TextMessage) {

// Приведение сообщения  к нужному типу TextMessage txtMsg = (TextMessage)msg;

// Вывод содержимого сообщения

System.out.println(txtMsg.getText()); }

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

40. Использование и назначение MDB. Создание  бина, управляемого сообщениями.

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

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

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

В некоторых отношениях бины, управляемые сообщениями, напоминают бины сеанса без состояния:

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

Реализуют интерфейс javax.jms.MessageListener.

41.MDB – компонента. Реализация интерфейса javax.jms.MessageListener.

Компоненты типа MDB (Message Driven Beans) работают асинхронно под управлением EJB-контейнера. Контейнер получает сообщение от клиента, точнее говоря, от службы сообщений, через которую действует клиент, активизирует MDB-компонент и обращается к его методам. Клиент никак не связан с MDB-компонентом, более того, клиент не подозревает о его существовании. Клиент обращается только к службе сообщений. Поэтому для MDB-компонента не нужны ни remote- ни home-интерфейсы, он состоит только из одного или нескольких классов. Класс MDB-компонента должен реализовать MessageDrivenBean.

Интерфейс MessageDrivenContext, расширяющий интерфейс EJBContext, ничего не добавляет к методам интерфейса EJBContext. Поэтому класс MDB-компонента может получить только сведения о транзакции, если он участвует в какой-либо транзакции. Более того, он не может воспользоваться методами интерфейса EJBContext, предоставляющими сведения о клиенте и ссылки на remote- и home-интерфейсы.

EJB-контейнер создает экземпляр MDB-компонента так же, как экземпляр  поэтому в нем должен быть  открытый конструктор по умолчанию  и метод ejbCreateO без аргументов. В  этом методе можно записать  начальные действия компонента.

Главное, что должен сделать класс MDB-компонента — это реализовать интерфейс-слушатель службы сообщений. Если MDB-компонент связан со службой сообщений JMS (Java Message Service), то он должен реализовать интерфейс MessageListener

Главная отличительная черта MDB. Единственный способ общения – посылка сообщений. MDB – это просто MessageListener, и ничего больше: класс реализует javax.ejb.MessageDrivenBean и javax.jms.MessageListener. Первый из этих интерфейсов имеет всего два метода:

setMessageDrivenContext и ejbRemove. Второй интерфейс имеет лишь один метод onMessage. Спецификация требует также создания метода ejbCreate без параметров.

Раз клиент не общается непосредственно с MDB, то он его и не создает.  Контейнер сам решит, когда и сколько ему требуется MDB для обработки сообщений из данного destination.

Интерфейс javax.jms.MessageListener предписывает реализовать всего один метод void onMessage(javax.jms.Message message). Как не трудно догадаться, этот метод вызывается получателем при получении сообщения (полученное сообщение передается в качестве аргумента метода), при этом выполнение потока не приостанавливается.

Главный недостаток MDB – он может принимать сообщения только из одного destination.

42.Технология  JSF(Java server faces). Компоненты ввода. Создание пользовательских компонентов: роль JSF компонентов, жизненный цикл, обработчики, инструменты отображения, структура JSF компонента

JavaServer Faces (JSF) — это фреймворк для веб-приложений, написанный на Java. Он служит для того, чтобы облегчать разработку пользовательских интерфейсов для Java EE-приложений. В отличие от прочих MVC-фреймворков, которые управляются запросами, подход JSF основывается на использовании компонентов.

Для создания проекта JSF понадобится:

·JSF implementation;

· JSF tags library;

·JDK

· Веб-контейнер для JSF (например Tomcat)

Стандартные компоненты JSF разделены на две части: 1) базовые компоненты JSF и 2) HTML-компоненты JSF.

Базовыми называются компоненты, которые не привязываются к рендерингу HTML или какому-либо другому механизму отображения.

HTML-компоненты отвечают за рендеринг разметки результирующей web-страницы (т.е. используются для отрисовки html). (юзаются теги как в html только с приставкой h:)

Фазы жизненного цикла:

·Восстановление представления - для запрошенной страницы либо извлекается дерево компонентов, либо создается новое дерево компонентов. Для компонентов запрашиваемой страницы восстанавливаются их прошлые состояния (веб-форма заполняет вводимыми значениями).

·Применение значений запроса - всем объектам дерева компонентов присваиваются соответствующие им значения из запроса.

·Обработка проверок - отправленные строковые значения преобразуются в "локальные значения", которые могут представлять собой объекты любого типа.

·Обновление значений модели - изменяются свойства привязанных к компонентам бинов.

·Вызов приложения - выполняется метод action кнопки или ссылки, щелчок по которой привел к отправке формы.

·Визуализация ответа - генерируется html и отправляется клиенту

 В JSF 2.0 в качестве обработчика представления используется технология Facelets которая пришла на замену JSP.

Для отображения данных обычно используется JSP, Facelets, но JSF можно приспособить и под другие технологии, например XUL.

JSF 2 лучше использовать:

·Когда проект только начался.

· Вам необходимо использовать отправку данных на сервер, при этом использовать серверную валидацию/конвертацию.

· AJAX.

· Богатый выбор готовых компонентов (PrimeFaces, ICEfaces, RichFaces, PrettyFaces, OpenFaces и др).

· Вы не хотите писать много JavaScript кода.

43. Стратегии  обработки асинхронных запросов  в контексте ЖЦ JSF. Визуальное  построение интерфейса с использованием  компонентов JSF.

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

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

Фазы жизненного цикла

• Восстановление представления (Restore View)
• Применение значений запроса (Apply Request Values)
• Выполнение проверок (Process Validations)
• Обновление значений модели (Update Model Values)
• Выполнение приложения (Invoke Application)
• Формирование ответа (Render Response)

JavaServer Faces поддерживает API, которое  сконцентрировано на компонентах. С помощью такого API собрать UI для Web-приложения максимально просто. Спецификация JSF определяет набор  базовых компонент пользовательского  интерфейса (в спецификации JSF упоминаются  как UI-компоненты).

Исходные или «стандартные» UI-компоненты в спецификации сопутствуют набору библиотек тэгов «Core» и «HTML». Библиотека тэгов стандартных компонент Core поддерживает общие для Web-приложения операции, такие как назначение проверок, конвертация входных значений и загрузку связок ресурсов. Библиотека HTML создает и визуализирует компоненты HTML. Она включает компоненты для отображения простых текстовых меток, полей ввода, ссылок и кнопок, так же как и более сложных компонент-контейнеров для отображения информации в табличном виде или панелей дочерних компонентов.

По умолчанию в JSF 2 используется технология отображения Facelets, которая представляет собой инфраструктуру шаблонов, во многом основанную на Tiles. JSF 2 также предоставляет мощный механизм так называемых составных компонентов,построенных на основе функциональности шаблонов Facelets и позволяющих создавать собственные компоненты без использования кода Java или XML-конфигурации.

Facelets сегодня является  стандартной технологией отображения  для JSF 2.x. Facelets - это облегченная платформа  шаблонов, которая поддерживает  все компоненты JSF пользовательского  интерфейса и используется для  построения и визуализации дерева  компонентов JSF для просмотра приложений.

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

44. Facelets - как основа технологии управления  представлением для Java Server Faces (JSF) и  альтернатива ранее используемой  в JSF технологии Java Server Pages (JSP).

Facelets — открытый веб-фреймворк, распространяемый под лицензией Apache license. Фреймворк требует для функционирования валидные XML документы. Это означает, что веб-страницы должны быть созданы с использованием языка разметки XHTML. Facelets поддерживает все компоненты JSF и создаёт собственное дерево компонент, отражая view для JSF-приложения.

Технология JavaServer Faces включает:

• Набор API для представления компонент пользовательского интерфейса (UI) и управления их состоянием, обработкой событий и валидацией вводимой информации, определения навигации, а также поддержку интернационализации (i18n) и доступности (accessibility).
• Специальная библиотека JSP тегов для выражения интерфейса JSF на JSP странице.

Призванная быть гибкой, технология JavaServer Faces усиливает существующие, стандартные концепции пользовательского интерфейса (UI) и концепции Web-уровня без привязки разработчика к конкретному языку разметки, протоколу или клиентскому устройству.

Интерфейс JSF-приложения состоит из страниц JSP (Java Server Pages), которые содержат компоненты, обеспечивающие функциональность интерфейса. При этом библиотеки тегов JSP используются на JSP-страницах для отрисовки компонентов интерфейса, регистрации обработчиков событий, связывания компонентов с валидаторами и конвертаторами данных и много другого.

JSF не имеет непосредственного  отношения к JSP: она лишь использует JSP через специальную библиотеку  тегов – своего рода мост. Жизненный  цикл компонент JSF сильно отличается  от цикла JSP-страниц. При этом технологию Facelets гораздо легче использовать  вместе с JSF, т.к. она изначально  проектировалась под нужды JSF.

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

Жизненный же цикл компонентов JSF не ограничивается JSP-страницей.

45. Интеграция технологии AJAX в Java Enterprise приложение. Динамическая подгрузка  данных на страницу. Использование Java Query API.

Ajax – это аббревиатура, означающая "Асинхронный JavaScript и XML" (Asynchronous JavaScript and XML). Основное назначение Ajax состоит в предоставлении веб-приложению возможности эффективной обработки взаимодействия между пользователем и веб-страницей, при этом значительно снижаются требования к обновлению или полной перезагрузке страницы при каждом взаимодействии с пользователем. Такой подход предоставляет широкие возможности при использовании браузера. Обработка взаимодействия Ajax осуществляется асинхронно в фоновом режиме. Благодаря этому пользователь может продолжать работу со страницей.

Для использования AJAX достаточно ввести

- ряд строк XML в XHTML

- несколько строк кода Java в управляемом бине (вот тут, по сути, и есть связь AJAX Java EE)

- проверку полей ввода  и отображения индикаторов выполнения

 Вызов AJAX необходимо связать  с каким либо событием

- например, keyup или blur, активизируемым  определённым компонентом

- затем определяются компопненты, которые должны быть выполнены  и подготовлены к отображению.

Связывание вызова AJAX:

- префикс f: ajax  ведёт в  facelets application

- добавляет компонент ajax к другому UI компоненту

- jsf.ajax.request() обеспечивает прямой доступ к методам AJAX

- f: ajax обеспечивает возможности  для любой компоненты

Динамическая подгрузка данных на страницу

Использование AJAX позволяет значительно сократить трафик при работе с веб-приложением благодаря тому, что вместо загрузки всей страницы достаточно загрузить только изменившуюся часть или вообще только получить/передать набор данных в формате JSON или XML, а затем изменить содержимое страницы с помощью JavaScript.

Или подгрузка контента при скроллинге

 jQuery это быстрая, небольшая и богатая возможностями JavaScript библиотека. Она позволяет очень просто делать такие вещи как: обход элементов или манипуляция элементами HTML документа или AJAX запросы. Не задумывайтесь о кросс-браузерности - это и многое другое берет на себя jQuery.

46. Библиотеки и компоненты JSF. Возможности  библиотеки визуальных компонентов RichFaces в качестве Faces компонентов  для JavaServer.

 JavaServer Faces - это технология на стороне сервера для разработки Web-приложений с богатым пользовательским интерфейсом.

Технология JavaServer Faces состоит из двух главных компонентов:

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

2. Библиотека пользовательских  тегов JSP для выражения интерфейса JavaServer Faces в странице JSP. Авторы страниц  могут использовать эту библиотеку  тегов для добавления компонентов  пользовательского интерфейса в  свои страницы.

Библиотеки и компоненты:

PrimeFaces, MyFaces, Tomahawk, Trinidad, Tobago, Orchestra, ICEFaces, OpenFaces, RichFaces.

RichFaces — библиотека компонентов  для JavaServer Faces, созданная на основе открытого фреймворка Ajax4jsf. Позволяет легко интегрировать технологию Ajax в enterprise приложение.

В дополнение к большому количеству готовых к использованию визуальных компонентов фреймворка Ajax4jsf, RichFaces также реализует поддержку скинов («skinnability» feature), предоставляя большое количество предопределённых скинов для настройки внешнего вида приложения.

Фреймворк реализован как библиотека компонентов, добавляющая поддержку технологии Ajax в существующие страницы таким образом, что разработчику не приходится писать код на JavaScript'e или заменять существующие компоненты новыми Ajax-виджетами widgets. RichFaces предоставляет «страничную» поддержку технологии Ajax в отличие от традиционной компонентной модели.

JavaScript Engine — RichFaces JavaScript-движок работает на стороне клиента. Он обновляет различные области на странице JSF на основе информации полученной из Ajax ответа. JavaScript-движок предоставляет API, поэтому разработчику не нужно создавать собственные функции JavaScript.

47. Перспективные технологии разработки  веб-ориентированных систем. Создание  многоуровневого распределения Java EE совместимого приложения с веб-приложением.

 Перспективные технологии веб-ориентированных систем

AJAX — подход к построению интерактивных пользовательских интерфейсов WEB-приложений, заключающийся в «фоновом» обмене данными браузера с WEB-сервером. В результате, при обновлении данных WEB-страница не перезагружается полностью, а WEB-приложения становятся более быстрыми и удобными.

jQuery — библиотека JavaScript, фокусирующаяся на взаимодействии JavaScript и HTML. Библиотека jQuery помогает  легко получать доступ к любому  элементу DOM, обращаться к атрибутам  и содержимому элементов DOM, манипулировать  ими. Также библиотека jQuery предоставляет  удобный API для работы с AJAX.

HTML5 («язык гипертекстовой  разметки») — стандартизированный  язык разметки документов во  Всемирной паутине. Большинство  веб-страниц содержат описание  разметки на языке HTML (или XHTML). Язык HTML интерпретируется браузерами; полученный  в результате интерпретации форматированный  текст отображается на экране  монитора компьютера или мобильного  устройства.

CSS ( Cascading Style Sheets — каскадные таблицы стилей) — формальный язык описания внешнего вида документа, написанного с использованием языка разметки.

ASP.NET (Active Server Pages для .NET) —  технология создания веб-приложений  и веб-сервисов от компании  Майкрософт.

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

48. Определение, основные  архитектурные принципы, модели  и методы разработки  решения задач в технологиях Spring mvc, Struts, AJAX

Spring – универсальная платформа с открытым исходным кодом, которая предоставляет облегченное решение по созданию готовых корпоративных приложений с возможностью использования RMI и Web-служб, отправки сообщений по электронной почте, обработки данных в базе данных, декларативного управления транзакциями, предоставляет среду выполнения MVC, способы интеграции АОП и хорошо структурированную иерархию исключений. 
Вохможности  
• Поддержка аспектно-ориентированного программирования (в том числе интеграция с AspectJ)  
• Язык выражений Spring (SpEL)  
• Встроенная поддержка Bean Validation API  
• Поддержка Object to XML Mapping  
• Интеграция с JEE  
• MVC на веб-уровне  
• Поддержка электронной почты 
• Поддержка планирования заданий 
MVC – это шаблон, который часто используется при реализации уровня презентаций в приложении. Главный принцип шаблона MVC состоит в определении архитектуры с четкой ответственностью для каждого компонента.  
В шаблоне MVC разделяют три участника.  
•Модель – представляет бизнес-данные.  
•Представление–отображает данные пользователя в желаемом формате.  
•Контроллер–обрабатывает запросы к действиям. 
Функции: 
• Настраиваемые компоненты MVC, которые хранятся в файле struts.xml.  
• Действия, основанные на POJO 
• Поддержка Ajax, которая используется для асинхронного запроса.  
• Поддержка интеграции с Hibernate, Spring, Tiles и так далее. 
Apache Struts — фреймворк с открытым исходным кодом для создания Java EE веб-приложений. Основывается на Java Servlet API и расширяет его, в архитектурном плане реализует паттерн MVC.

AJAX (аббревиатура от «Asynchronous Javascript And Xml») – технология обращения к серверу без перезагрузки страницы. 
За счет этого уменьшается время отклика и веб-приложение по интерактивности больше напоминает десктоп. 
Под AJAX подразумевают любое общение с сервером без перезагрузки страницы, организованное при помощи JavaScript. 
Возможности: 
--Элементы интерфейса. В первую очередь AJAX полезен для форм и кнопок, связанных с элементарными действиями. 
--Динамическая подгрузка данных. Например, дерево, которое при раскрытии узла запрашивает данные у сервера. 
--Живой поиск. Пользователь начинает печатать поисковую фразу, а JavaScript предлагает возможные варианты. 
Технически, с помощью AJAX можно обмениваться любыми данными с сервером. 
Обычно используются форматы: 
•JSON•XML•HTML/текст•Бинарные данные, файлы