JINI

Концепция Jini была впервые представлена фирмой Sun Microsystems в начале 1999 года. С тех пор она претерпела некоторые изменения, сделанные сообществом Jini ( Jini Community ), которое сейчас включает такие компании, как 3Com, Canon, Epson, Kodak, Motorolla, Nokia, Novell, Quantum, Segate, Sharp, Siemens, Sony, Xerox.

Jini - это набор API и сетевых протоколов, которые призваны помочь построить и развернуть распределенную систему, организованную как федерация сервисов. Сервисы могут быть всем, что выполняется в сети и готово выполнить какое-либо действие, - аппаратными устройствами, программами и т.д. Например, Jini -совместимые принтеры могут предлагать сервис печати, Jini -совместимые видеокамеры - сервис съемки и просмотра изображения. Таким образом, федерация служб является набором сервисов, доступных в сети в данный момент, которыми могут воспользоваться клиенты для достижения некоторой цели.

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

Jini определяет инфраструктуру времени выполнения, которая обеспечивает механизм, позволяющий добавлять, удалять, находить и получать доступ к сервисам. Инфраструктура времени выполнения состоит из трех звеньев: сервиса поиска, поставщиков услуг (таких как Jini -совместимые устройства) и клиентов. Служба поиска является важнейшим механизмом для систем, использующих Jini. Когда в сети становится доступным новый сервис, он регистрируется в службе поиска. Когда клиент хочет найти службу, он запрашивает ее у службы поиска.

Инфраструктура времени выполнения использует один протокол сетевого уровня, называемый "обнаружение" ( discovery ) и два протокола объектного уровня, называемые "объединение" ( join ) и "поиск" ( lookup ). Обнаружение позволяет клиентам и службам обнаружить службу поиска. Объединение позволяет службам регистрироваться в службе поиска. Поиск позволяет клиенту опрашивать сервисы в поисках тех, которые ему нужны.

Процесс обнаружения

Обнаружение работает следующим образом: предположим, существует Jini -совместимый принтер, который предоставляет услугу печати. Как только принтер будет подключен к сети, он пошлет оповещение присутствия посредством отправки пакета на зарезервированный для службы JINI -порт. В оповещение присутствия включается IP -адрес и номер порта, через который принтер может общаться со службой поиска.

Рис. 16.1. Отправка оповещения присутствия

Сервис поиска ожидает пакеты оповещения присутствия, и как только получает такой пакет - открывает его и инспектирует. Пакет содержит информацию, которая позволяет службе поиска определить, должна ли она связаться с отправителем пакета. Если это так, она соединяется с отправителем напрямую, создавая TCP -соединение по IP -адресу и номеру порта, полученному из пакета. Используя RMI, сервис поиска посылает к источнику пакета объект, называемый регистратором. Назначение объекта-регистратора заключается в обеспечении возможности будущего взаимодействия со службой поиска. Вызывая методы этого объекта, отправитель оповещающего пакета может выполнить объединение и поиск службы поиска. В случае с принтером служба поиска должна создать TCP -соединение с принтером и послать ему объект-регистратор, через который принтер смог бы зарегистрировать свою службу печати через процесс объединения.

Процесс объединения

Как только поставщик сервиса получает объект-регистратор, он может выполнить объединение - т.е. стать частью федерации сервисов,

Рис. 16.2. Объединение

Рис. 16.3. Передача элемента службы

зарегистрированных в службе поиска. Чтобы выполнить объединение, поставщик сервиса вызывает метод register(), принадлежащий объекту-регистратору, передавая в качестве параметра объект, называемый элементом службы, который является пакетом объектов, описывающих службу. Метод register() посылает копию элемента службы сервису поиска, где хранится элемент службы. После этого поставщик сервиса завершает процесс объединения: его служба теперь зарегистрирована в службе поиска.

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

Процесс поиска

После того как служба зарегистрирована в службе поиска в процессе объединения, она становится доступной для использования клиентами. Для построения распределенной системы служб клиент должен иметь возможность найти определенные службы.

Для выполнения поиска клиент задействует метод lookup() объекта- регистратора. Клиент передает в качестве аргумента метода lookup() шаблон службы - объект, являющийся критерием поиска при опросе. Шаблон службы может включать ссылки на массив объектов типа Class. Эти объекты указывают ищущей службе тип (или типы) Java -объекта службы, требуемые клиенту. Клиент получает ссылку на совпавший объект обслуживания в качестве возвращаемого значения метода lookup().

Рис. 16.4. Поиск службы

Рис. 16.5. Взаимодействие клиента и службы

В общем случае клиент ищет сервис по типу Java. Например, если клиенту необходимо использовать принтер, он должен пересылать службе поиска шаблон сервиса, включающий объект Class с интерфейсом служб печати (все службы печати должны реализовать этот единый интерфейс).

Разделение интерфейса и реализации

Архитектура Jini использует одно из фундаментальных свойств Java -объектов - разделение интерфейса и реализации. Например, обслуживающий объект может предоставить клиенту доступ к службе многими способами. Объект может сам представлять собой службу, которая загружается клиентом во время поиска, а затем выполняется локально. С другой стороны, обслуживающий объект может лишь выступать удаленным представителем запрашиваемой службы. При этом, когда клиент вызывает методы обслуживающего объекта, он посылает запрос по сети к серверу, который и выполняет реальную работу.

Важное свойство архитектуры Jini состоит в том, что сетевой протокол, используемый для общения между представителем объекта и удаленной службой, не должен быть известен клиенту, поскольку он является частью реализации службы - он разрабатывается и реализуется разработчиком службы. Клиент может общаться со службой по этому протоколу, поскольку служба вводит некоторый свой код (в объекте службы) в клиентское адресное пространство. Введенный обслуживающий объект должен связываться со службой через RMI, CORBA, некоторый смешанный протокол, построенный на сокетах и потоках, или используя какой-то другой способ взаимодействия. Клиенту не нужно заботиться о сетевом протоколе, поскольку он может общаться с интерфейсом, реализованным обслуживающим объектом. Именно обслуживающий объект заботится обо всех необходимых сетевых коммуникациях. С точки зрения клиента служба выглядит как интерфейс, независимо от того, как эта служба реализована.

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