47. Spring mvc.Отображение и выбор представления в Spring mvc. Реализацией интерфейса ViewResolver и отрисовка представления пользователю. Яна

Как спринг Spring MVC определяет какое представление необходимо отобразить для определенного запроса? Для этого используется интерфейс ViewResolver.

Диспетчер сервлетов DisptacherServlet Spring’а с помощью ViewResolver определяет какое представление необходимо использовать на основании полученного имени.

Этапы:

• Вначале диспатчер сервлет (диспетчер) получает запрос, далее он смотрит свои настройки, чтобы понять какой контроллер использовать (на рисунке Handler Mapping).

• После получения имени контроллера запрос передается в него (на рисунке Controller). В контроллере происходит обработка запроса и обратно посылается ModelAndView (модель – сами данные; view (представление) – как эти данные отображать).

• Диспатчер сервлет на основании полученного ModelAndView ищет какое представление ему использовать (View Resolver) и получает в ответе имя представления View

• В представление передаются данные (model) и обратно, если необходимо, посылается ответ от представления.

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

ViewResolver – распознователь представлений. Интерфейс ViewResolver в Spring MVC поддерживает распознавание представлений на основе логического имени, возвращаемого контроллером. Для поддержки различных механизмов распознавания представлений предусмотрено множество классов реализации. Например, класс UrlBasedViewResolver поддерживает прямое преобразование логических имен в URL. Класс ContentNegotiatingViewResolver поддерживает динамическое распознование представлений в зависимости от типа медиа, поддерживаемого клиентом (XML, PDF, JSON и т.д.). Существуют также несколько реализаций для интеграций с различными технологиями представлений, такими как FreeMarker (FreeMarkerViewResolver), Velocity (VelocityViewResolver) и JasperReports (JasperReportsViewResolver).

InternalResourceViewResolver – реализация ViewResolver, которая позваляет находить представления, которые возвращает контроллер для последующего перехода к нему. Ищет по заданному пути, префиксу, суффиксу и имени.

48. Spring boot. Базовые принципы и особенности архитектуры. Преимущество использования и сравнение с другими Фреймворками Spring. Саша

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

Spring Boot обладает большим функционалом, но его наиболее значимыми особенностями являются: управление зависимостями, автоматическая конфигурация и встроенные контейнеры сервлетов

Чтобы ускорить процесс управления зависимостями, Spring Boot неявно упаковывает необходимые сторонние зависимости для каждого типа приложения на основе Spring и предоставляет их разработчику посредством так называемых starter-пакетов (spring-boot-starter-web, spring-boot-starter-data-jpa и т.д.)

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

После выбора подходящего starter-пакета, Spring Boot попытается автоматически настроить Spring-приложение на основе добавленных вами jar-зависимостей

Например, если вы добавите Spring-boot-starter-web, Spring Boot автоматически сконфигурирует такие зарегистрированные бины, как DispatcherServlet, ResourceHandlers, MessageSource

Если вы используете spring-boot-starter-jdbc, Spring Boot автоматически регистрирует бины DataSource, EntityManagerFactory, TransactionManager и считывает информацию для подключения к базе данных из файла application.properties

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

49. Web – сервисы Понятие СОА, назначение, основные принципы и возможности, преимущества и недостатки применения Web-сервисов. Понятие WEB-сервисов, ключевые технологии Web-сервисов, структура, назначение и использование (XML, WSDL, SOAP, UDDI). Структура и основные элементы описания сервиса в WSDL. НАСТЯ

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

Сервис-ориентированная архитектура (СОА) – модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами. Представляет собой стиль создания архитектуры ИТ, направленный на превращение бизнеса в ряд связанных сервисов - стандартных бизнес-задач, которые можно при необходимости вызывать через сеть.

Принципы СOA

-Архитектура, как таковая, не привязана к какой-то определённой технологии,

-Независимость организации системы от используемой вычислительной платформы (платформ),

-Независимость организации системы от применяемых языков программирования,

-Использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним,

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

Используемые стандарты:

1)XML: Расширяемый язык разметки, предназначенный для хранения и передачи структурированных данных;

2)SOAP: Протокол обмена сообщениями на базе XML;

(конверт (envelope), определяющий рамочную структуру сообщения в формате XML, набор правил для представления типов данных, соглашение о представлении вызова удаленных процедур (в режиме RPC), правила совместного выполнения протоколов SOAP и HTTP. SOAP может использовать также комбинацию различных сетевых протоколов, таких как HTTP, SMTP, FTP, RMI/IIOP.)

3)WSDL: Язык описания внешних интерфейсов веб-службы на базе XML;

4)UDDI: Универсальный интерфейс распознавания, описания и интеграции (Universal Discovery, Description and Integration). Каталог веб-служб и сведений о компаниях, предоставляющих веб-службы во всеобщее пользование или конкретным компаниям.

Достоинства веб-служб

/ Веб-службы обеспечивают взаимодействие программных систем независимо от платформы

/ Веб-службы основаны на базе открытых стандартов и протоколов. Благодаря использованию XML достигается простота разработки и отладки веб-служб

/ Использование интернет-протокола обеспечивает HTTP-взаимодействие программных систем через межсетевой экран

Недостатки веб-служб

/ Меньшая производительность и больший размер сетевого трафика по сравнению с технологиями RMI, CORBA, DCOM за счёт использования текстовых XML-сообщений. Однако на некоторых веб-серверах возможна настройка сжатия сетевого трафика.

Документ WSDL содержит следующие элементы:

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

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

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

• Операция – это абстрактное определение операции для сообщения, например, присвоение имени методу, очереди сообщений или бизнес-процессу, которое примет и обработает сообщение.

• Тип порта – это абстрактный набор операций, сопоставленный с одной или несколькими конечными точками, определяющий набор операций для привязки; коллекция операций, как она абстрактна, может быть сопоставлена ​​с несколькими транспортными средствами через различные привязки.

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

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

• Сервис – это набор связанных конечных точек, охватывающий определения сервиса в файле; службы сопоставляют привязку с портом и включают любые определения расширяемости.

50. Технология SOAP Web – сервисов на основе API, JAX-RPC. Пример кода реализации. ПОЛИНА

SOAP - это протокол доступа к простым объектам, использующий данные в формате XML, отправленные http. Он может проходить через платформы и межсетевые экраны. SOAP не является проприетарным протоколом для веб-сервисов.

SOAP=http+xml

JAX-RPC – это Java API для XML RPC. Его можно использовать для создания клиентов и Web-сервисов, использующих XML и RPC. RPC работает через такие XML-протоколы, как SOAP, определяющие структуру обертки, правила кодирования и соглашения по представлению RPC-вызовов и ответов на них, передаваемых в виде SOAP-сообщений через HTTP. Преимущество JAX-RPC состоит в том, что сложность SOAP-сообщений скрыта от разработчика. Вот как это работает:

Разработчик указывает удаленные процедуры (Web-сервисы), которые могут быть вызваны клиентами через Java-интерфейс, и реализует этот интерфейс. Для клиента Web-сервис выглядит как набор методов, реализующих бизнес-логику от имени клиента. Клиент обращается к Web-сервису, используя Service Endpoint Interface, как определено в JAX-RPC. Разработчики клиента создают автоматически генерирующееся прокси (локальный объект, представляющий удаленный сервис), а затем просто вызывают методы прокси. Разработчику не нужно волноваться насчет генерирования или разбора SOAP-сообщений, все это выполняет runtime JAX-RPC. Заметьте, что J2EE Web-сервисы могут быть вызваны любым Web-клиентом, и что любой J2EE-клиент может обратиться к любому Web-сервису.

Заметим, что J2EE-приложение может использовать Web-сервисы, опубликованные другими провайдерами, независимо от того, как именно они реализованы. В случае не-Java клиентов и сервисов схема слегка изменится. Как уже говорилось, все, что происходит между вызовом и получением ответа, скрыто от глаз. Вы работаете с привычной семантикой языка Java, то есть с вызовами методов и типами данных. Нет причины думать об отображении Java на XML и наоборот, или о конструировании SOAP-сообщений. Вся эта низкоуровневая работа остается за сценой, позволяя сконцентрироваться на высокоуровневых проблемах.