Архитектуры распределенных приложений. Web-сервисы
Простейшей архитектурой распределенного приложения является архитектура клиент-сервер.
Серверная часть оказывает услуги, клиентская их использует. В архитектуре клиент-сервер важно правильно распределить нагрузку между клиентом и сервером. Можно сделать клиента “тонким”, только отображающим результаты запроса. Это удобно для клиента (дешевый компьютер, простое ПО), но не удобно для “толстого” сервера (большая нагрузка, вся обработка данных). Толстый сервер трудно модернизировать, наращивать его мощность. Можно наоборот сделать клиента “толстым”, выполняющим всю обработку результатов запроса, а сервер “тонким”, только рассылающим всю необходимую информацию. В этом случае для клиентов требуется дорогие ПК и дорогое ПО.
Чтобы избавиться от недостатков архитектуры клиент-сервер используются дополнительные программы для обработки данных. Их выделяют в отдельный (промежуточный middleware) слой ПО.
Распределенное приложение становиться трехслойным. В технологии JAVA промежуточный слой обычно реализован сервером приложений (JBOSS, IBМ WEB Sphere, и т.д.).
В технологии JAVA промежуточный слой делится на две части: Web-слой (сервлеты, jsp-страницы), EJB-слой (EJB-компоненты).
Количество слоев можно увеличивать, но важнее установить тесную связь, между компонентами распределенного приложения. Компоненты распределенного приложения созданы на основе сокетов, RMI и CORBA-технологии, тесно связаны с платформой и выбранной технологикй. В этом случае горят о тесно связанных (tightly coupled) распределенных приложениях. Распределенные приложения, компоненты которого могут работать на разных платформах и заменять друг друга называются слабосвязанными (loosely coupled). Создатели Web-services решили, что Web-услуги будут предоставляться в рамках слабосвязанных приложений. В этих целях они решили использовать общие для всех платформ средства, т.е. язык HTML и протокол HTTP. Однако, оказалось что средств HTML недостаточно для описания вызовов распределенных процедур и методов. Выход был найден в использовании языка XML. XML используется на всех платформах, документы XML легко передаются по сети в виде текстовых файлов с расширением *.xml. Таким образом Web-services услуги предоставляемые по интернет с использованием языка XML и протокола HTTP. При этом обмен информации между клиентом и сервером осуществляется в виде XML-документов.
Web-service (Web-служба) – компонент распределенной системы реализующий Web-services услуги.
Jms. Архитектура jms
JMS (Java Message Service) – Java-технология создания распределенных приложений, основанная на обмене сообщений. JMS – “старая’ технология (1998 г.). В настоящее время пакет javax.jms входит в состав последних версий jdk.
Всякая реализация этой технологии называется поставщиком JMS (provider JMS). В настоящее время программные реализации созданы рядом независимых производителей. Наиболее популярными JMS от Sun, MQService от IBM, JMS WebLogic от Bea. B общем виде архитектура JMS выглядит так:
Прикладные программы использующие JMS называются клиентами JMS (JMS-Client). Система обработки сообщений управляющая маршрутизацией и доставкой сообщений называется JMS-provider (JMS-провайдер). Средства администрирования (Administrative tool) средства управления ресурсами используемые клиентами. JNDI (Java Naming and Directory Interface) это система Java именования и поиска объекта на основе класса NameContext, в JNDI NameSpace – пространство имен.
JMS – поддерживает две модели сообщений – “издание-подписка” и “точка-точка” (“Publish-Subseribe”, “Point-to-Point”). В зависимости от реализации системы, любая из этих моделей может обеспечивать синхронный или асинхронный обмен сообщениями.
Модель “точка-точка” предполагает отправку сообщений все получателям по одиночке.
Сообщения отправляется в очередь. В очереди они обрабатываются: “первый зашел – первый вышел” (FIFO), т.е. адреса получает сообщения в том порядке в котором они были отправлены.
В тоже время в модели “издание-подписка”сообщения могут быть отправлены нескольким получателям.
Сообщения публикуются в определенной теме. В каждой теме могут публиковаться несколько сообщений. Клиентское приложение, желающее получить сообщения должно сначала подписаться на него. Подписаться на определенную тему сообщения могут несколько клиентов. Все они получают копии всех сообщений данной темы. Обычно в момент публикации сообщений в системе должен быть хотя бы один получатель. Если получатель не подключен к сети, сообщения уничтожаются. Такая подписка называется недолговечной. Имеется долговременная подписка, когда получатель может использовать все накопившееся за его отсутствие по данной теме. Долговременная подписка требует большого количества ресурса.