Опубликован: 18.03.2010 | Доступ: свободный | Студентов: 839 / 85 | Оценка: 4.48 / 4.33 | Длительность: 12:01:00
Лекция 1:

Основные платформы и технологии

Лекция 1: 1234 || Лекция 2 >

Технология SOAP

Основное содержание SOAP (Simple Object Access Protocol) состоит в обмене сообщениями между удаленными объектами по протоколу HTTP с использованием XML в качестве транспорта. Спецификация SOAP поддерживается и развивается консорциумом W3C (см. http : //www .w3.org/TR/SOAP/).

По функциональным возможностям технология SOAP весьма сходна с первыми версиями CORBA.Однако у нее есть одно несомненное достоинство: простота. На уровне передачи данных в глобальных сетях, между предприятиями, где большой сложности взаимодействие не предвидится - это оптимальное решение по соотношению время разработки/функциональность. Существуют многочисленные мосты (CORBA/SOAP, C++/SOAP, Java/SOAP).

Технологии COM/DCOM и .NET

COM (Component Object Model) - это стандарт Microsoft,определяющий структуру и взаимодействие компонентов программного обеспечения в современных операционных системах MS Windows.Архитектура современных Windows -приложений основана на COM:мир этих приложений - это мир COM -компонент. Компоненты COM обладают уникальностью и предоставляют другим компонентам COM стандартным образом описанные интерфейсы, позволяющие получить доступ к методам этих компонентов. COM определяет механизм связи только между локальными (т.е. находящимися на том же компьютере) компонентами.

DCOM (Distributed Component Object Model) - это распределенная версия COM, обеспечивающая механизм связи между удаленным COM -компонентами (т.е. находящимися на разных компьютерах, но в среде MS Windows).Фактически DCOM это COM с добавленным к последнему механизмом RPC (remote procedure call).Сходную функциональность взаимодействия удаленных Windows -приложений можно получить с использованием активно развиваемой в последнее время фирмой Microsoft технологии .NET.Важно подчеркнуть, что упомянутые в данном разделе технологии относятся исключительно к операционным системам Microsoft.

Технология Enterprise Java Beans

Архитектура EJB - это компонентная архитектура, предназначенная для разработки и развертывания распределенных бизнес-приложений, основанных на компонентах. Приложения, созданные с помощью архитектуры EJB,являются масштабируемыми, ориентированными на транзакции и безопасными при работе в многопользовательском режиме. Эти приложения, однажды написанные, могут затем быть развернуты на любой серверной платформе, поддерживающей спецификацию EJB.Это определение можно немного упростить при помощи описанных ранее понятий. Enterprise Java Beans - это стандартная модель серверных компонентов для мониторов компонентных транзакций. Enterprise Bean -компоненты являются Java (J2EE) объектами, реализующими технологию Enterprise Java Beans (EJB).Каждый такой компонент выполняется под управлением сервера приложений, который должен соответствовать так называемой спецификации EJB- контейнера, т.е. поддерживать соответствующий API - EJB Container API (обычно сервер приложений в таком случае называют EJB -контейнером). EJB -контейнер предоставляет компонентам (Enterprise Beans) сервисы системного уровня (например, многопоточность, механизм транзакций), оставаясь при этом прозрачным для разработчика приложений. Эти системные сервисы позволяют разработчику быстро создавать и разворачивать Enterprise Bean -компоненты: контейнер как бы "закрывает" от разработчика EJB все сложности системного характера (например, уже упомянутые многопоточность или механизм транзакций), позволяя ему сосредоточиться исключительно на бизнес-логике приложения. Enterprise Bean -компонент - это объект требуемого класса, описанного на языке программирования Java,расположенный на стороне сервера приложений и выполняющий часть бизнес-логики приложения (этим занимается собственно код компонента, осуществляющий задачи приложения). Например, в приложении контроля инвентаря, Enterprise Bean -компоненты могут реализовывать бизнес-логику приложения в методах checkInventoryLevel() и orderProduct(). Вызывая эти методы, удаленные клиенты могут получать доступ к инвентарным сервисам приложения.

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

  • Первой причиной является тот факт, что EJB -контейнер предоставляет все необходимые сервисы системного уровня, позволяя разработчику Bean- компонента сконцентрироваться на решении бизнес-задач. Именно EJB- контейнер (а не Bean -разработчик) является ответственным за обеспечение работоспособности таких механизмов, как транзакции и авторизация доступа.
  • Вторым преимуществом EJB -компонентов является их расположение на сервере. Вследствие этого, разработчикам клиентов не приходится включать бизнес-логику в состав клиентского приложения - в таком коде не должно быть функциональности, реализующей бизнес-правила или доступ к базам данных. В результате, клиентское приложение получается гораздо меньшего размера, что очень важно для выполнения на устройствах с ограниченными ресурсами.
  • Третьим преимуществом Enterprise Bean -компонент является их переносимость, сборщик приложений может собирать новые приложения из уже существующих Bean -компонент. Такие приложения могут быть запущены на любом J2EE -совместимом сервере.

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

  • Приложение должно быть масштабируемым. Чтобы подстроится к растущему количеству пользователей, разработчикам, возможно, придется распределить компоненты приложения между несколькими серверами. Вне зависимости от компоновки компонент на серверах, их расположение остается прозрачным для клиентов.
  • Требуется механизм транзакция для обеспечения целостности данных. Enterprise Bean -компоненты поддерживают транзакции - механизм, управляющий одновременным доступом к разделяемым объектам.
  • У приложения будет множество клиентов. Требуется всего несколько строк кода в клиентских приложениях для нахождения Enterprise Bean -компонент. Клиентские приложения могут быть небольшими, многочисленными и различными.

На сегодняшний день корпорацией Sun Microsystems было выпущено пять спецификации EJB - EJB 1.0, EJB 1.1, EJB 2.0, EJB 2.1 и EJB 3.0. В спецификации EJB 1.0 были впервые описаны сеансовые (session bean) и объектные (entity bean) компоненты. Спецификация EJB 1.1 расширяет спецификацию EJB 1.0EJB 2.0 были добавлены компоненты, управляемые асинхронными сообщениями JMS (Java Messaging Service),а также EJB Query Language (EQL) - язык запросов. В EJB 2.1 был модифицирован и улучшен EQL, добавлена возможность вызова объектных компонент через HTTP/SOAP.Также компоненты, управляемые сообщениями, смогли принимать сообщения не только по протоколу JMS,но и по другим протоколам. Последняя на данный момент версия EJB - EJB 3.0.В ней модифицированы механизмы описания компонент (вместо XML -файла - метаданные), а сам процесс разработки переведен на JAVA 5.0.

Технология JINI

Jini представляет собой технологию создания распределенных систем, ориентированную исключительно на использование Java.В настоящий момент Jini является торговой маркой Sun Microsystems.

Технология Jini состоит из трех основных компонентов:

  • Инфраструктура.Включает в себя распределенную систему защиты, которая интегрирована в RMI (Remote Method Invocation),представляющий собой механизм для нахождения, активации и захвата объектов сервисов.Инфраструктура состоит из объектов, использующих протоколы для передачи информации во время транзакций. На уровне транзакций происходят запросы и передача информации. Для поиска объектов и передачи информации между ними используется менеджер транзакций (transaction manager).Обязанности менеджера транзакций этим не ограничиваются. Помимо этого, он обязан координировать работу системы во время выполнения запросов и передавать найденую по этим запросам информацию;
  • Модель программирования использует язык программирования Java и компоненты JavaBeans для организации интерфейсов транзакций и написания приложений, использующих модель распределенных вычислений;
  • Сервисы имеют определенный унифицированный интерфейс и набор методов, посредством которых возможно общение с ними. Реализация сервисов не требует использования программной модели Jini,однако эта модель необходима при взаимодействии сервисов между собой. Причем сервисы в этом случае чем-то подобны процессам в Unix.Каждый сервис может использовать другие сервисы для выполнения своих задач, а также порождать новые сервисы, специализирующиеся на решении определенных вопросов.

В отличие от EJB,технология JINI не требует наличия специальных серверов приложений. Кроме того, если модель использования EJB принципиально двух- или трехзвенна (существует клиент, запрашивающий методы EJB,работающий под управлением контейнера, и, как правило, сервер, например, СУБД, к которому обращается в процессе работы EJB,причем иерархия запросов в этой схеме строго задана), то в модели JINI все сервисы абсолютно равноправны между собой (каждый из них может быть как сервером, так и клиентом к любому). Такая "равноправная" архитектура взаимосвязей называется одноранговой (peer-to-peer).В модели JINI сервисы представляют, таким образом, своего рода "интеллектуальные устройства" (можно представить себе в качестве примера сервис печати), общающиеся между собой по стандартизованным правилам, имеющие стандартизованные имена, общую модель безопасности и т.п. Такой универсум сервисов-"интеллектуальных устройств" JINI принято называть JINI Federation."Интеллектуальные устройства" могут сами добавлять себя в этот универсум (например, сервис печати при включении принтера) или, наоборот, выходить из него (сервис печати при выключении принтера), без необходимости какого-либо "внешнего" воздействия (диспетчера, оператора и т.п.)

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

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

Технология Jini разрабатывалась с целью создания системы, которая бы требовала к себе мало внимания при обслуживании, успевала за постоянным изменением и наращиванием системы и обеспечивала постоянную доступность сервисов посредством Интернета. Безопасность системы и конфиденциальность информации передаваемой в сети достигается за счет распределенной системы безопасности. Наращиваемость систем возможна за счет добавления новых, наследования и изменения старых сервисов, доступных посредством интернет. Постоянная доступность становится возможной за счет рассредоточенности системы, в которой можно изменять приложения беспрерывно, так, что сервис будет доступен из Интернета постоянно.

Лекция 1: 1234 || Лекция 2 >
Антон Зубеков
Антон Зубеков

Здравствуйте, подскажите пожалуйста где можно достать материалы по курсу Кросс-платформенные и многозвенные технологии, о которых говориться, к примеру, в Лекции 2. Пример "Служба мгновенных сообщений"