Процессы жизненного цикла программных систем. Процессы соглашения

Вопросы:

Процессы жизненного цикла программных систем. Процессы соглашения

Жизненный цикл ПО

Весь период существования ПО начиная с момента принятия решение о разработке, до прекращения его использования.

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

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

Модель жизненного цикла ПО выделяет конкретные наборы видов деятельности (активности), артефактов, ролей и их взаимосвязи.

§ какие артефакты являются входными данными у каких видов деятельности,

§ и какие артефакты появляются в качестве результатов,

§ какие роли вовлечены в различные активности,

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

§ каковы критерии качества полученных результатов,

§ как оценить степень соответствия различных артефактов общим задачам проекта

§ когда можно переходить от одной деятельности к другой.

Процессы жизненного цикла ПО.

Процессы соглашения

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

§ процесс приобретения (покупка),

§ процесс поставки (разработка).

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

§ процесс менеджмента модели жизненного цикла;

§ процесс менеджмента инфраструктуры;

§ процесс менеджмента портфеля проектов;

§ процесс менеджмента людских ресурсов;

§ процесс менеджмента качества.

Процессы проекта

§ относятся к планированию, оценке и управлению проектами

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

§ процесс планирования проекта;

§ процесс управления и оценки проекта.

Процессы поддержки проекта:

§ процесс менеджмента решений;

§ процесс менеджмента рисков;

§ процесс менеджмента конфигурации;

§ процесс менеджмента информации;

§ процесс измерений показателей.

Технологические процессы разработки программных систем.

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

Технические процессы

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

§ определение требований правообладателей;

§ анализ системных требований;

§ проектирование архитектуры системы;

§ процесс реализации;

§ процесс комплексирования системы;

§ процесс квалификационного тестирования системы;

§ процесс инсталляции программных средств;

§ процесс поддержки приемки программных средств;

§ процесс функционирования программных средств;

§ процесс сопровождения программных средств;

§ процесс изъятия из обращения программных средств.

Процессы реализации программных систем.

Процессы реализации программных систем (ПС)

§ используются для создания конкретного элемента системы.

§ процесс анализа требований;

§ процесс проектирования архитектуры;

§ процесс детального проектирования;

§ процесс конструирования;

§ процесс комплексирования;

§ процесс квалификационного тестирования.

Процессы повторного применения программных систем. Процессы поддержки программных систем.

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

§ процесс проектирования доменов;

§ процесс менеджмента повторного применения активов;

§ процесс менеджмента повторного применения программ.

Процессы поддержки ПС

§ помогают процессу реализации программных средств

§ процесс менеджмента документации;

§ процесс менеджмента конфигурации;

§ процесс обеспечения гарантии качества;

§ процесс верификации;

§ процесс валидации;

§ процесс ревизии;

§ процесс аудита;

§ процесс решения проблем.

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

§ проста, естественна, имеет некоторую привязку к ГОСТу;

§ полная и согласованная документация на каждом этапе;

§ легко определить сроки и затраты на проект.

Недостатки:

§ достаточно продолжительный цикл разработки по времени (система морально устаревает);

§ трудно оценить качество;

§ все требования должны быть утверждены в начале проекта;

§ значительные затраты ресурсов на составление документации.

Итерационная

§ Основной принцип: выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы.

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

§ возможность корректировки ошибок;

§ более эффективное управление рисками.

Недостатки:

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

§ при итерациях приходится отбрасывать часть сделанной ранее работы;

§ снижение ответственности разработчика.

Спиральная модель

§ Основной принцип: каждый «виток спирали» содержит все стандартные стадии ЖЦ, по его окончании формируется прототип ИС.

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

§ пользователь может получить прототип системы;

§ сведение к минимуму количества неточностей в требованиях;

§ нечувствительность к изменениям требований;

Недостатки:

§ недостаточное документирование прототипа;

§ недостаточное внимание качеству;

§ процесс без надлежащего контроля может быть длительным;

Фазовое измерение

Основные принципы:

§ отражение этапов выполнения проекта и сопутствующие им события (вехи);

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

Способы описания

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

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

Виды нотаций

Диаграммы потоков данных (data flow diagrams). Содержат: процессы, представляющие собой любые трансформации данных в рамках описываемой системы, хранилища данных, внешние по отношению к системе сущности и потоки данных между элементами трех предыдущих видов.

Диаграммы сущностей и связей (entity-relationship diagrams). Используются для представления структуры данных изображающие набор сущностей предметной области и связей между ними.

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

Технология разработки MSF

Технология разработки RUP.

Схема потока работ в XP

 

Методология Scrum.

Scrum

Product Owner

Отвечает за разработку продукта, принятие окончательных решений

Управляет ожиданиями заказчиков и всех заинтересованных лиц

Координирует и приоритизирует Product backlog

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

Отвечает за приемку кода в конце каждой итерации

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

Команда (Team)

Берет на себя обязательства по выполнению объема работ на спринт.

В Scrum вклад отдельных членов проектной команды не оценивается.

Типичные размер команды – 7 плюс минус 2.

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

По окончанию Sprint дола быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели).

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи, которые должны быть выполнены в текущем спринте.

Каждый день производится Daily Scrum: каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?».

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

Методология KANBAN.

Канбан

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

Основные принципы

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

Классификация

Бизнес-требования (Business Requirements) определяют высокоуровневые цели организации или клиента (потребителя) - заказчика разрабатываемого ПО.

Пользовательские требования (usabitity)

Системные требования (интеграция, окружение, защита)

 Информационные потребности (форматы выдачи и хранения информации)

Изучение предметной области

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

Сборщики проектов. Maven.

Apache Maven — фреймворк для автоматизации сборки проектов на основе описания их структуры в файлах на языке POM (англ. Project Object Model), являющемся подмножеством XML. Проект Maven издаётся сообществом Apache Software Foundation, где формально является частью Jakarta Project.

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

Maven используется для построения и управления проектами, написанными на Java, C#, Ruby, Scala, и других языках.

Среди примечательных альтернатив — система автоматической сборки Gradle, построенная на принципах Apache Ant и Maven, но использующая специализированный DSL на Groovy вместо POM-конфигурации.

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

Включает такие действия, как:

· компиляция исходного кода в объектный модуль,

· сборка бинарного кода в исполняемый файл,

· выполнение тестов,

· развёртывание программы в целевой среде,

· написание сопроводительной документации или описание изменений новой версии.

Основное средство автоматизации сборки — применение специализированного инструмента; один из ранних и исторически значимых инструментов является утилита make, во многом определившая стиль и методы для инструментов, появившихся позднее. Один из таких элементов — формат Makefile, поддерживаемый в большинстве широко используемых инструментов (Automake, CMake, imake, qmake, nmake, wmake, Apache Ant, Apache Maven, OpenMake Meister, Gradle). Ключевые требования, предъявляемые средствам автоматизации — поддержка технологий непрерывной интеграции, в частности, постоянных «ночных сборок», управление зависимостями исходного кода, обеспечение разностной сборки, уведомление при совпадении исходного кода (после сборки) с имеющимися двоичными файлами, предоставление удобных отчётов о результатах компиляции и компоновки, автоматический запуск тестов и условное выполнение в зависимости от результатов прохождения.

Виды автоматизации, применяемые в различных инструментах:

· автоматизация по запросу (on-demand automation): запуск пользователем сценария в командной строке,

· запланированная автоматизация (scheduled automation): непрерывная интеграция, происходящая в виде ночных сборок,

· условная автоматизация (triggered automation): непрерывная интеграция, выполняющая сборку при каждом подтверждении изменения кода (commit) в системе управления версиями.

18. Системы контроля версий. Git.

Git — распределённая система управления версиями.

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

Здесь в игру вступают распределённые системы контроля версий (РСКВ). В РСКВ (таких как Git, Mercurial, Bazaar или Darcs) клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) — они полностью копируют репозиторий. В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных.

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

Подвиды data flow

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

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

Замкнутый цикл управления (closed - loop control) обработка постоянно непредсказуемо поступающих событий. Общий диспетчер событий классифицирует и отдает событие его на асинхронную обработку.

Подвиды data flow

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

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

Замкнутый цикл управления (closed - loop control) обработка постоянно непредсказуемо поступающих событий. Общий диспетчер событий классифицирует и отдает событие его на асинхронную обработку.

Основные шаги реализации

• Выделить структуру данных, с которыми система работает, и набор операций над ними.

• Реализовать механизм передачи изменений.

• Реализовать необходимые представления.

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

• Спроектировать и реализовать связь между обработчиком и представлением.

• Реализовать построение системы из компонентов и их инициализацию.

Дополнительные аспекты реализации:

• Динамические представления.

• Инфраструктура и иерархия представлений и обработчиков.

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

Недостатки

• Возрастание сложности разработки.

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

• Представления, модели и обработчикипочти никогда нельзя переиспользовать по отдельности.

28. Архитектура MV*:

REST

В технологии передачи репрезентативного состояния (Representational State Transfer, REST), как и SOAP, используется протокол HTTP.

Основная идея – назначение уникального идентификатора URL каждой веб-службе, каждому ресурсу.

Ресурс — это любая сущность, на которую клиент может поставить ссылку или с которой может попытаться взаимодействовать

Каждый ресурс должен и иметь URI.

Параметры веб-службе передаются как параметры форм.

Каждая веб-служба отображается в один из методов протокола HTTP.

Представление ресурса — это любая полезная информация о состоянии ресурса.

Ресурсы должны быть связаны максимально сильно связаны друг с другом (как вершины графов).

Пример REST запроса

POST /users HTTP/1.1

Host: myserver

Content-Type: application/xml

<?xml version="1.0"?>

<user>

<name>Robert</name>

</user>

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

Хорошим тоном является использование хотя бы основных HTTP кодов ответов.

Фильтрация

GET /books?color=red

Сортировка

GET /books?sort=-year,+name

Микросервисная архитектура.

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

Преимущества:

§ система может существовать параллельно с уже существующими модулями,

§ достаточно браузера,

§ система может расширяться различными не связанными разработчиками.

Клиентский сайт

Микросервис

База данных

Имеющиеся модули информационной системы

Рисунок. 1- Микросервисная архитектура информационной системы

Config Server на базе Spring Cloud Config — масштабируемое хранилище настроек.

Auth Server –выдает токены для доступа к ресурсам микросервисов. Auth server используется как для авторизации пользователей, так и для защищенного общения сервис-сервис внутри системы.

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

 

Рисунок. 2 – Набор сервисов микросервисной платформы

 

Service discovery –позволяет автоматически определять сетевые адреса для доступных экземпляров сервисов.

Circuit Breaker – основная идея состоит в том, чтобы остановить каскадный отказ в распределенной системе.

 

Сквозная функциональность.

Сквозная функциональность

могут применяться ко всем слоям, компонентам и уровням.

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

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

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

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

Управление исключениями. Обрабатывать и протоколировать исключения и обеспечивать уведомления.

Протоколирование. Выбрать данные, подлежащие протоколированию, как сделать протоколирование настраиваемым.

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

Структура фреймворка

Внедрение зависимости.

Внедрение зависимостей — это стиль настройки объекта, при котором поля объекта задаются внешней сущностью. DI — это альтернатива самонастройке объектов.

class ClassA { var classB: ClassB }

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

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

Варианты создания:

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

 

class ClassA {

var classB: ClassB

fun someMethodOrConstructor() { classB = ClassB() classB.doSomething() }

}

Недостатки

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

§ ClassA невозможно протестировать

§ СlassA должен знать, как создать ClassC и использовать его для создания ClassB.

1. внедрять зависимости через пользовательский класс - обработка зависимостей в пользовательском классе

 

class ClassA {

var classB: ClassB

constructor(classB: ClassB){ this.classB = classB }

}

Недостатки

• пользовательский код нетривиален и сложен в управлении.

1. Ответственность за обработку зависимостей возлагается на третью сторону

 

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

Scope

singleton (Default) Scopes a single bean definition to a single object instance per Spring IoC container.

prototype Scopes a single bean definition to any number of object instances.

request Scopes a single bean definition to the lifecycle of a single HTTP request; that is, each HTTP request has its own instance of a bean created off the back of a single bean definition. Only valid in the context of a web-aware Spring ApplicationContext.

session Scopes a single bean definition to the lifecycle of an HTTP Session. Only valid in the context of a web-aware Spring ApplicationContext.

application Scopes a single bean definition to the lifecycle of a ServletContext. Only valid in the context of a web-aware Spring ApplicationContext.

Реализация компонентного программирования в.NET.

EJB Возможности.

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

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

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

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

· поддержка событий

· поддержка именования и каталогов (JNDI)

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

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

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

Контейнеры EJB-container

Java-приложениям для работы нужна виртуальная машина JVM (Java Virtual Machine). Сеансовым компонентам и компонентам MDB для работы точно также необходим контейнер EJB. Можно считать EJB-container развитием базовой идеи JVM. Так же, как JVM прозрачно управляет памятью, EJB-container обеспечивает компоненты EJB такими службами, как обработка транзакций, поддержка безопасности, удаленные взаимодействия и веб-службы.

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

В Java технологиях контейнеры не ограничены только EJB3. Контейнер Java EE – это сервер приложений с поддержкой EJB3, веб-контейнеров (сервлеты, JSP, JSF, Struts, GWT) и других Java EE API и служб. Примерами реализаций контейнеров Java EE могут служить следующие серверы приложений: Oracle WebLogic, GlassFish, IBM WebSphere, JBoss и Caucho Resin.

Модели обмена сообщениями.

Модели обмена сообщениями

«point - to - point»:

• Каждое сообщение имеет только одного адресата.

• Сообщение попадает в «очередь» (queue) адресата и может быть прочитано когда угодно. Если адресат не работал в момент отсылки сообщения, сообщение не пропадёт.

• После получения сообщения адресат посылает извещение-подтверждение.

«publish-subscribe»:

• Подписчик подписывается на определённую «тему» (topic).

• Издатель публикует своё сообщение. Его получают все подписчики этой темы.

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

Организация VCL -приложения

Организация VCL-приложения

TApplication осуществление управления приложением.

Методы:

CreateForm Создание окна главной формы

Run реализует главную петлю программы:

выборка сообщений из очереди,

передача его на обработку.

Событие OnMessage реагирует на большинство сообщений посылаемых Windows.

Главная форма - форма, которая создаётся первой, становится главной, и её закрытие означает закрытие всего приложения.

VCL-приложение создаёт два окна: невидимое окно объекта Application и окно главной формы.

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

Обработка сообщений в VCL

Для каждого компонента создаётся уникальная оконная процедура, которая передаёт управление методу TWinControl.MainWndProc.

TWinControl.MainWndProc передаёт управление методу, указатель на который хранится в свойстве TControl.WindowProc. По умолчанию это - метод компонента WndProc.

TControl.WndProc осуществляет обработку некоторых сообщений, но в большинстве случаев передаёт управление методу Dispatch, который ищет среди методов компонента или его предков обработчик данного сообщения.

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

TWinControl.DefaultHandler самостоятельно обрабатывает некоторые сообщения, но большинство из них передаётся оконной процедуре, адрес которой хранится в свойстве TWinControl.DefWndProc (по умолчанию это стандартная функция Win API DefWindowProc).

Типы сообщений

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

struct DECLSPEC_DRECORD TMessage {

unsigned Msg;

struct {

NativeUInt WParam;

NativeInt LParam;

NativeInt Result; };

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

struct DECLSPEC_DRECORD TWMPaint {

unsigned Msg;

HDC DC;

NativeInt Unused;

NativeInt Result; };

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

TWMKey – сообщения нажатия клавиш,

TWMMouse – сообщения от «мыши».

Типы обработчиков сообщений

void __fastcall (__closure * TNotifyEvent) (TObject* Sender)

void __fastcall (__closure * TKeyPressEvent) (TObject* Sender, WideChar &Key)

void __fastcall (__closure * TDragOverEvent)(TObject* Sender, TObject* Source, int X, int Y, TDragState State, bool &Accept);

Java Messaging System

распределенная система, основанная на асинхронном обмене сообщениями (messages) между компонентами системы.

Message-Oriented Middleware (MOM) – это продукт, на основе которого и строится Messaging System.

Java Message Service (JMS) – это Java API (набор интерфейсов и классов) для работы с MOM.

{Queue|Topic}ConnectionFactory – создание JMS Connection. Администратор МОМ создает данный объект и связывает его с деревом JNDI.

{ Queue | Topic } Connection – абстрактное представление реального соединения между клиентом JMS и MOM.

{ Queue | Topic } Session – создается JMS Connection и используется клиентами для посылки и принятия сообщений.

Queue | Topic – доступ к представлению очереди или темы.

QueueSender, TopicPublisher – отправка сообщений.

QueueReceiver, TopicSubscriber – приём сообщений из очереди или темы:

• синхронно (метод recive()),

• для асинхронного приёма с помощью метода setMessageListener (MessageListener listener) задаётся ссылка на класс, переписывающий метод public void onMessage(Message message).

{ Object | Text | XML } Message – доступ к полям сообщений (реализуют интерфейс Message).

Основные классы JMS

Создание сессии

createQueueSession |createTopicSession (boolean transacted, int acknowledgeMode)

acknowledgeMode:

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

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

CLIENT_ACKNOWLEDGE – клиент должен вызвать метод acknowledge() интерфейса javax.jms.Message для того, чтобы явно подтвердить получение сообщения. При вызове данного метода будет подтверждено получение текущего и всех предыдущих полученных сообщений.

Типы сообщений

StreamMessage Считывать можно со стандартных интерфейсов ввода/вывода.

MapMessage Содержит информацию на подобии коллекций в виде ключ-значение (String, Object).

TextMessage Обычное, текстовое сообщение.

ObjectMessage Для передачи Serializable -объектов.

BytesMessage Список не интерпретированных байт. С его помощью можно передавать файлы.

Sender

Properties p = new Properties();

***

Context ctx = new InitialContext(p);

QueueConnectionFactory qcf =(QueueConnectionFactory)

ctx.lookup("java:comp/DefaultJMSConnectionFactory");

QueueConnection con = qcf.createQueueConnection();

QueueSession session =

con.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

Queue queue = null;

try {

queue = (Queue)ctx.lookup("MyQueue");

}

catch(NameNotFoundException nnfe)

   {

  queue = session.createQueue("MyQueue");

ctx.bind("MyQueue",queue);

} }

Reciver синхронный

Properties p = new Properties();

***

Context ctx = new InitialContext(p);

QueueConnectionFactory qcf

=(QueueConnectionFactory) ctx. lookup("java:comp/DefaultJMSConnectionFactory");

QueueConnection con = qcf. createQueueConnection();

QueueSession session = con. createQueueSession(false,Session.AUTO_ACKNOWLEDGE);

Queue queue = null;

queue = (Queue) ctx. lookup("MyQueue");

QueueReceiver receiver = session. createReceiver(queue);

con. start();

for(;;){

TextMessage textMessage = (TextMessage) receiver. receive();

   System.out.println("Got a message:"+ textMessage. getText());

}

Reciver асинхронный

public class AsyncR implements MessageListener {

public AsyncR(){ }

public void onMessage (Message message){

TextMessage textMessage = (TextMessage) message;

System.out.println("Got a message: "+textMessage.getText());

}

public static void main(String[] args) {

***

Context ctx = new InitialContext(p);

QueueConnectionFactory qcf = (QueueConnectionFactory)ctx.lookup("java:comp/DefaultJMSConnectionFactory");

QueueConnection con = qcf. createQueueConnection();

QueueSession session = con. createQueueSession(false,Session.AUTO_ACKNOWLEDGE);

Queue que ue = (Queue) ctx. lookup("MyQueue");

QueueReceiver receiver = session. createReceiver(queue);

con. start();

AsyncR async = new AsyncR();

receiver.setMessageListener(async);

Thread.sleep(100000000); }

Передача объекта

Card c = new Card ("Piter",new Date(),"1",0.0);

message.setObject (c);

producer.send (message);

public class Card implements Serializable

public class ObjectListener implements MessageListener {

public ObjectListener (BillingService bs)

{ this.bs = bs; }

public void onMessage (Message message) {

ObjectMessage msg = null;

 if (message instanceof ObjectMessage) {

msg = (ObjectMessage) message;

Object o = msg.getObject ();

System.out.println("Reading message: " + o);

if (o instanceof Card) Card c = (Card)o;

Программирование событий в.NET.

Состояние Entity

transient - экземпляр entity только создан, но не связан с контекстом. Entity не имеет постоянное представительство в базе данных и, как правило не имеет идентификатора.

managed или persistent - entity имеет соответствующий идентификатор и связан с контекстом. Entity может или не может физически существовать в базе данных.

detached – entity имеет связанный идентификатор, но больше не связана с контекстом (обычно, так как контекст был закрыт или экземпляр entity был удалён из контекста)

removed - entity имеет связанный идентификатор и связана с контекстом, однако запланировано её удаление из базы данных.

Классы entityManagerа и сессии имеют методы для изменения и контроля состояния entity.

Класс EntityManager

EntityManager

интерфейс, который описывает API для всех основных операций над Enitity.

Основные операции:

1) Для операций над Entity: persist (добавление Entity под управление JPA), merge (обновление), remove (удаления), refresh (обновление данных), detach (удаление из управления JPA), lock (блокирование Enity от изменений в других потоках).

2) Получение данных: find (поиск и получение Entity), createQuery, createNamedQuery, createNativeQuery, createStoredProcedureQuery.

3) Получение других сущностей JPA: getTransaction, getEntityManagerFactory, getCriteriaBuilder, getMetamodel.

4) Общие операции над EntityManager или всеми Entities: close, isOpen, getProperties, setProperty, clear

@PersistenceContext — аннотация используется для указания EntityManager, который необходимо ввести как зависимость.

Основы Hibernate, HQL.

Hibernate

Структура Hibernate

 

Hibernate Q