Заметьте, что в данном случае мы показали управляемый сообщениями компонент вместе с интерфейсами, которые он реализует. Поскольку он всегда реализует эти интерфейсы, целесообразно просто показать сам класс компонента. Наличие стереотипа неявно идентифицирует интерфейсы, реализуемые компонентом.
Возможности моделирования управляемых сообщениями компонентов в UML
Ясно понять и выразить взаимоотношения компонента, управляемого сообщениями, с системой можно с помощью различных средств UML. Эти средства позволяют, в частности:
· моделировать совокупность сообщений, которые могут быть отправлены или получены данным компонентом;
· моделировать функции, которые выполняют в системе адресаты;
· показывать отношения между классами компонентов и их пользователями.
Моделирование сообщений
Вся связь с компонентами, управляемыми сообщениями, протекает посредством асинхронных сообщений. Такие сообщения должны принадлежать к классу javax.jms. messageили к одному из его потомков.
Ясно, что клиент должен знать, сообщения какого рода ожидаются компонентом. Однако сам компонент не имеет никаких формализованных механизмов для передачи этих сведений пользователям.
В языке UML сообщение можно изобразить как зависимость между типом сообщения и подсистемой управляемого сообщениями компонента. По этой зависимости клиент будет определять компонент и связываться с ним, поэтому он должен иметь такую же зависимость от типа сообщения, чтобы иметь возможность создавать такие сообщения и отправлять их клиенту.
Пример этих отношений показан на рис. 14.2.
Моделирование адресатов
Управляемый сообщениями компонент для клиента непосредственно не виден. Поэтому клиент не может адресовать сообщения определенному компоненту. Он просто находит определенного адресата и посылает сообщения ему. Компонент получает сообщения от адресата, с которым он связан, и обрабатывает их.
В JMS поддерживаются два типа адресатов сообщений.
· Тема. Тема позволяет передавать сообщения по принципу публикации и подписки.Тема может быть опубликована для нескольких клиентов; в свою очередь, на тему могут подписаться несколько компонентов и получать приходящие в нее сообщения. Подписаться на тему можно на длительный или на краткий срок. Длительная подписка подразумевает, что сообщения, направленные в тему, доставляются, даже если сам компонент не существует. Длительную подписку полезно использовать при создании надежных и высокодоступных систем.
· Очередь. Отличие очереди от темы состоит в том, что, хотя в очередь могут посылать сообщения разные издатели, из очереди их может принимать только один компонент. Сообщения, посылаемые отправителями, помещаются в очередь в порядке поступления и обрабатываются компонентом по мере их получения из очереди. В наиболее простом случае очередь имеет одного отправителя и одного получателя. Эта схема иногда также называется двухточечной передачей.
Интересно, что с программной точки зрения не существует прямого отношения между выбранным для компонента адресатом и самим компонентом, управляемым сообщениями. Производитель компонента предоставляет эти сведения декларативно через описатель развертывания. Однако для разработчика все же будет целесообразно выразить эту информацию в модели UML, чтобы яснее показать смысл компонента и используемый подход, если это существенно для проекта. Для этой цели можно применить меченое значение {Destination-Queue} или {Destination=Topic}. Пример приведен на рис. 14.3.
Технология компонентов, управляемых сообщениями
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.