На сегодняшний день, наиболее распространенной моделью является Client/Server. Ниже представлена типичная Cliet/Server архитектура:

В Client/Server архитектуре, клиенты опрашивают сервер, и сервер возвращает необходимые данные и производит нужные операции над ними. На сегодняшний день существуют разные сервера в Inet: Web сервера, Mail сервера, FTP и т.д. Архитектура Client/Server — это пример централизованной архитектуры, где вся сеть зависит от центральных узлов, называемых серверами, предназначенных для обеспечения необходимых сервисов. Без серверов такая архитектура не имеет никакого смысла. Независимо от наличия в сети клиентов, сеть будет существовать исключительно при условии существования серверов.

Подобно архитектуре Client/Server, P2P также распределенная вычислительная модель(!!!), но существует очень важная отличительная черта. Архитектура P2P — это децентрализованная архитектура (смотрите рис 2), где в сети не существует понятия клиента или сервера. Каждый объект в сети, назовем его peer (англ. равный, такой же), имеет тот же статус, это означает, что этот объект может выполнять как функции клиента (отсылать запросы) так и сервера (получать ответы).

И хотя все peers имеют одинаковый статус, это не значит, что они должны иметь одинаковые физические возможности. P2P сеть может состоять из peers с разными возможностями, начиная от мобильных устройств и заканчивая mainframes. Некоторые мобильные peer могут и не поддерживать всех функциональных возможностей серверов, в силу ограничения их ресурсов (слабый процессор/небольшой объем памяти), однако сеть никак не ограничивает их.

Обе сетевые модели имеют свои преимущества и недостатки. Визуально вы можете видеть, что рост Client/Server системы (которая тем больше чем клиентов в нее добавлено) приводит к росту нагрузок на сервер. C каждым новым клиентом центральный узел слабеет. Таким образом, сеть может становиться перегруженной.

P2P сеть работает по другому сценарию. Каждый объект в сети (peer), является активным в сети, peer предоставляет некоторые ресурсы в сети, такие как пространство для хранения данных и дополнительные такты CPU. Чем больше peer в сети, тем больше производительность самой сети. Следовательно, по мере того как растет сеть, она становится мощнее.

Также P2P отличается от Client/Server модели тем, что P2P система считается рабочей, если в ней есть хотя бы один активный peer. Система будет считаться неактивной, если ни один peer не активен.

Однако существуют и недостатки у P2P систем. Во-первых, управление такой сетью намного сложнее, чем управление Client/Server системами, где администрирования требует только центральный узел — Server. Таким образом, нужно затратить намного больше усилий на поддержку security, backup, и т.п. Во-вторых, P2P протокол намного более "разговорчивый" — peer может присоединиться к сети или выйти из нее в любой момент, и это может отрицательно сказаться на производительности (Расмотрите "Bandwidth Barriers to Gnutella Network Scalability" для дополнительной информации.)

Разные протоколы, разные архитектуры, разная реализация. Это точно соответствует описанию текущих P2P систем. На сегодняшний день, разработчики используют разные методологии и подходы при создании P2P систем. Стандарты, которых предостаточно в Client/Servers системах, заметно отсутствуют для P2P. Для решения этого дефицита, Sun разработал JXTA.

Цитата с JXTA:

Project JXTA занимается разработкой базы сетевой вычислительной технологии для обеспечения набора несложных, небольших и гибких механизмов, позволяющих реализовать P2P систем для любой платформы и в любое время. Этот проект сначала обобщает функциональность P2P систем, а потом строит основы технологии, направленные на преодоление сегодняшних ограничений для P2P протоколов. Цель проекта — создание базовых механизмов, выбор способов их использования предоставлен разработчикам приложений.

JXTA стремится к обеспечению основной инфраструктуры P2P, на основе которой могут создаваться другие P2P приложения. Эта база состоит из набора протоколов, которые не зависят ни от конкретного языка программирования, ни от конкретной платформы, ни от конкретного типа сетевого соединения или транспортного протокола. Эти протоколы решают только самые необходимые задачи для построения обобщенных P2P систем. Простые протоколы с низким объемом служебной информации нацелены, цитируя заявление авторов JXTA, на "любое устройство с цифровым пульсом".

JXTA определяет шесть протоколов, но от peers не требуется реализовывать все из них. Количество протоколов, которые реализует peer, зависит от его возможностей, возможно, кому-то будет достаточно и одного. Кроме того, peers могут расширять или заменять протоколы в зависимости от своих потребностей.

Важно заметить, что протоколы JXTA не гарантируют взаимодействия между собой. Здесь, вы можете провести параллель между JXTA и TCP/IP. Оба протокола FTP и HTTP созданы поверх TCP/IP, но вы не можете получить доступ к WEB странице через FTP. Точно та же картина с JXTA. То, что две системы созданы поверх JXTA, еще не означает, что они могут взаимодействовать между собой. Разработчики должны сами спроектировать приложения таким образом, чтобы они могли взаимодействовать. Однако, разработчики могут использовать JXTA, обеспечивающий базовый уровень для взаимодействия, с целью упрощения решения проблем взаимодействия.

Бесспорно, первый шаг к обеспечению универсального уровня протокола — это применение подходящей для большинства доступных на сегодняшний день платформ формата представления данных. XML — это идеальный кандидат для такой задачи. Разработчики на JXTA осознают, что XML становится общепринятым стандартом для обмена данными. XML обеспечивает универсальный, независимый от языка и платформы формат передачи данных. XML может быть легко трансформирован в другие кодировки. Следовательно, формат XML используется для всех JXTA протоколов.

Хотя сообщения в JXTA определено в XML формате, JXTA не зависит от XML. Фактически, клиенты JXTA не требуют XML парсеров; это дополнительный компонент. Просто думайте об XML как о согласованной форме представления данных в JXTA. PDA устройства, такие как мобильные тел. должны использовать прекомпилированные XML сообщения.

Перед тем как идти дальше давайте быстро рассмотрим разные концепции в JXTA.

Peers (пользователь) Любая сущность в сети, реализующая один или несколько протоколов JXTA. Peer — ом может быть любое устройство от mainframes до мобильных телефонов или даже просто сенсорных мониторов. Peer существует независимо и общаются между собой асинхронно.

Peer Groups (Группа пользователей) Peers с общими интересами могут образовывать группы. Границы групп peers не ограничены границами физического сетевого домена.

Messages (Сообщение) Все коммуникации в сети JXTA происходят путем отсылки и получения сообщений. Эти сообщения, называемые JXTA сообщениями, придерживаются стандартного формата, который является ключом для способности к взаимодействию.

Pipes (Канал) Pipes организует виртуальный коммуникационный канал в JXTA окружении. Peer-ы используют его для отправки и получения сообщений. Pipes считается виртуальным, потому что peers не должны знать их настоящих адресов для того, что бы их использовать. Это очень важная абстракция.

Services (Услуги) Как peers так и peer groups могут предлагать сервисы. Сервис, предложенный отдельным peer, на личном уровне, является Peer Services, и концептуально является эквивалентом централизации. Никакой другой peer не обязан предлагать такой же сервис; если peer в данный момент не доступен, то и сервис становится недоступным.

Сервис, предложенный Peer group, называется peer group services. В отличие от peer services, этот сервис может быть предоставлен несколькими peer в сети. Доступ к такому сервису осуществить проще, так как сервис будет доступен, пока доступен хотя бы один peer в группе.

Codats Codats (Code/Data), в JXTA, означает, что его содержимое будет одновременно и кодом и данными. Codats может быть опубликован, просмотрен, и реплицирован в случае надобности.

Advertisement (Объявление) Объявления печатает и просматривает любые JXTA ресурсы такие как peer, peer group, pipe, codat. Объявление имеет форму XML документа.

Identifiers (Идентификатор) Идентификатор играет ключевую роль в среде JXTA. Идентификатор специфицирует ресурсы, а не физические адреса в сети. Идентификатор в JXTA определен как URN (Уникальный имя ресурса). URN это не что иное как URI (Уникальный идентификатор ресурса), который должен оставаться глобально уникальным и постоянным, даже если ресурс, на который он ссылался, исчез.

World peer group (Всемирная группа пользователь) Каждый JXTA peer по умолчанию принадлежит к world peer group. Каждый JXTA peer знает о world peer group, даже если он не может найти никаких других peers в сети. Более того, даже peers без доступа в сеть принадлежат world peer group.

Net peer group (Сетевая peer группа) В локальной сети, сетевой администратор обычно конфигурирует таким образом что каждый peer в сети может присоединиться к net peer group. Эта группа похожа на DHCP (dynamic host configuration protocol) сервис .Net peer group обеспечивают peers глобальное соединение согласно ограничениям, установленным администратором.

Rendezvous peers (рандеву peer) Рандеву peers — это специальный peer который сохраняет информацию о других peers. Таким образом, рандеву peer может помочь peers находить другие peers в сети. Rendezvous peer может перенаправить поиск к другому кendezvous peer.

Endpoints (адресаты) Endpoints — это адресаты в сети которые могут быть представлены в сети через сетевой адрес. Peers не используют endpoints напрямую, они используют их через pipes, которые созданы поверх endpoints.

Routers (Роутер) Все, что двигает пакеты внутри JXTA протокола, называется JXTA router. Не все peer должны быть routers. Peers которые не являются routers должны найти routers в сети для роутинга их сообщения.

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

Peer Discovery Protocol (PDP)

Peer Resolver Protocol (PRP)

Peer Information Protocol (PIP)

Peer Membership Protocol (PMP)

Pipe Binding Protocol (PBP)

Endpoint Routing Protocol (ERP)

Лучший способ увидеть эти протоколы в действии — рассмотреть связку JXTA и Java, стандартную реализацию JXTA на языке Java. Разработчики могут использовать существующую реализацию или реализовать собственную версию протоколов на языках и платформах по своему выбору. Хотя стандартная реализация использует протоколы HTTP и TCP/IP из-за их простоты и популярности, вы можете реализовать протоколы JXTA на основе любых транспортных протоколов, в зависимости от топологии сети.

Рассмотрим реализацию JXTA на Java в ее сегодняшнем состоянии.

Реализация состоит из двух главных иерархий классов:

• Классы net.jxta
• Классы net .jxta.impl

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

Где мой peer?

Вложенность групп peer.

Группы peer как приложения.

public void init(PeerGroup group, Advertisement adv);
public int startApp(String[] args);
public void stopApp();

Каналы и адресаты.

Объявления.

Сервисы.

Как упоминалось ранее, проект JXTA — открытое сообщество, в котором участвуют разработчики open- source, технологические энтузиасты и студенты. Любой может принять участие в развитии технологии. На Jxta. org есть несколько интересных проектов. Рассмотрим некоторые из них:

JXTA Shell

Instant P2P

В этой статье я познакомил вас с системами peer- to- peer. Вы узнали, что JXTA предлагает для мира P2P. Я также описал несколько важных терминов и концепций, используемых программистами, создающими приложения для JXTA.

JXTA — перспективная низкоуровневая платформа для создания P2P приложений. Поскольку Java — предпочтительный язык для разработки приложений, рассчитанных на работу в неоднородных средах, это естественный выбор для P2P-приложений. Надеюсь, эта статья достаточно заинтересовала вас, чтобы начать исследовать мир P2P и Java.

Navaneeth Krishnan is senior product engineer at Aztec Software and Technology Solutions, where he has designed and developed several e-commerce solutions and frameworks for clients. He is an active P2P enthusiast and currently deeply involved with Jxta. He owns iPeers, a Jxta community project that deals with the integration of artificial intelligence in P2P networks.

• Visit the Project Jxta home page: http://www.jxta.org/
• The Jxta Protocol Specification and other whitepapers are available here: http://www.jxta.org/white_papers.html
• The Jxta Shell project home page: http://shell.jxta.org/
• The CMS home page: http://cms.jxta.org/
• The InstantP2P home page: http://instantp2p.jxta.org/
• To learn more about scalability problems faced in the Gnutella network, read "Bandwidth Barriers to Gnutella Network Scalability" (Clip2, September 2000):http://www.clip2.com/dss_barrier.html
• Learn more about URIs, URLs, and URNs: http://www.ietf.org/rfc/rfc2396.txt
• "The Gnutella File-Sharing Network and Java," Ken McCrary (JavaWorld, October 2000): http://www.javaworld.com/javaworld/jw-10-2000/jw-1006-fileshare.html
• Mark Johnson reports from JavaOne 2001 on the motivation for a new P2P protocol in "Get Connected with Jxta" (JavaWorld, June 2001): http://www.javaworld.com/javaworld/javaone01/j1-01-jxta.html
• For more articles on Enterprise Java, browse the JavaWorld Topical Index: http://www.javaworld.com/channel_content/jw-enterprise-index.shtml
• Sign up for JavaWorld's free weekly email newsletters: http://www.idg.net/jw-subscribe
• You'll find a wealth of IT-related articles from our sister publications at IDG.net