Ты забыл добавить первая реализация TCP-IP в ядре BSD тоже его рук дело.

Прочитано 4ре страницы их сайта, ничего конкретного не понятно. Не нравятся мне такие сайты..

Кто разобрался, в чем там смысл?

JXTA technology is a set of open protocols that allow any connected device on the network ranging from cell phones and wireless PDAs to PCs and servers to communicate and collaborate in a P2P manner.

JXTA peers create a virtual network where any peer can interact with other peers and resources directly even when some of the peers and resources are behind firewalls and NATs or are on different network transports.

Project JXTA Objectives

Interoperability - across different peer-to-peer systems and communities
Platform independence - multiple/diverse languages, systems, and networks
Ubiquity - every device with a digital heartbeat

the Possibilities...

Find peers and resources on the network even across firewalls
Share files with anyone across the network
Create your own group of peers of devices across different networks
Communicate securely with peers across public networks

--
esli eto ne ponyatno - uchit' english

btw, eshe faq est: http://www.jxta.org/project/www/docs/DomainFAQ.html#whatisProjectJXTA

Кто-нибудь уже пробовал JavaServerTM Faces ?

The JavaServerTM Faces Technology Tutorial - http://java.sun.com/j2ee/javaserverfaces/docs/JSFTOC.html

Java Web Services Developer Pack 1.2 Download - http://java.sun.com/webservices/downloads/webservicespack.html

В разделе Документация на сайте читай General Papers.

Пытаясь дать самое краткое определениеение,: "distributed computing over HTTP"

Anode

Честно говоря, весьма непонятно, чем "distributed computing over HTTP" лучше чем "distributed computing over TCP/IP".
Разве что лишним overhead :-)

ХУЙНЯ!!!!!!!!!!!!!!! все это, становится похоже на M$ - "все дело в волшебных пузырьках", а по-сути топтание на месте

2 anonymous (*) (2003-06-11 13:03:50.221503) спасибо

2 dimentiy надо добавить также: "distributed computing over HTTP (как пример, или over TCP/IP, UDP or whatever)" Протоколы как языко-независимы так и не зависят от реализации несущей (конкретная имплементация определяет underlying protocol).

Почему HTTP - чтобы сделать прокси и файерволы прозрачными (это - главная мотивация). А если пиры внутри одной сети - то конечно же HTTP не используем.

файерволы и прокси - сегодняшняя реальность и JXTA предлагает сделать всё прозрачным (использовав существующую инфраструктуру) и пользовать новый тип security "based on id", а всё остальное - скрыть под JAXTой.

Прокси и файерволы конечно реальность... Но может быть проще будет открыть специальные лечебные заведения для администраторов и "IT манагеров" -- параноиков. Почистить софт и откатиться лет на 10 назад, когда файрволами защищали, то, что действительно стоило защищать...

2 anonymous (*) (2003-06-11 13:03:50.221503) Сколько раз я ни пробовал это дело (с первой реализации) - тоже так думал (теми же словами), смотря на бесконечные ожидания, тормознутость такой сети вообще исходящая из дизайна - и откладывал. Но глядя к чему идёт интернет (gnutella, freenet, SETI@home, edonkey (и прочая шарная компания) с одной стороны и то что разработчикам приходится во всех сетевых аппликухах изобретать велосипед - с другой, а с третьей - что таким людям как джой не пристало заниматься муйнёй (по крайней мере так долго + денежки то Sun'a), то я бы был бы по-осторожнее в суждениях.

BTW HTTP overhead (в простейших случаях) - несколько литер. Пример: "GET X HTTP/1.0\n\n"

2 anonymous (*) (2003-06-11 18:50:36.600851)

да, я согласен, что самое эффективное решение было бы всех построить и сказать: мы ребята имеем сегодня проблему и чтобы не создавать следующие уровни (а кто знает - кто-то может начать делать файерволы и над жакста - лэером, а там - по новой ;-) то давайте выбросим всю эту шелуху (proxy, firewalls) ровно в MMddhhmmyy и будем пользовать новый security от Sun, он чессное слово секур ;-) В этом случае - да - мы будем минимальный оверхэд.

Было очень интересным и правильным шагом разрабатывать сначала фаерволы, а потом придумывать как с ними бороться! Похожая позиция у любителей веб-сервисов: "как же! у нас все работает через фаерволы!". А не задумывались, что если стои фаервол и на нем закрыт доступ на что-то, не следует придумывать технологию, которая "обходит" эту защиту? Если нужен доступ куда-то, открой его. Если у тебя нет на это правов, не фиг и лезть тогда.

Ну паронаидальные фаерволы на вес и вся это конечно плохо.
Но с другой сторомы когда все работает только через один порт(ну или два если нужен SSL) и протокол, то и управлять и мониторить это проще.

HP и Dell будут предустанавливать Жабу по дефолту на свои ящики
как на desktop'ы так и на notebook'и с серверами

http://www.heise.de/newsticker/data/tol-12.06.03-002/

Предлогаю переименовать dotNET в deadNET :))

2Anode:

Я согласен с анонимусами, говорившими о том, что не надо "бороться" с firewalls. В компаниях открыто то, что нужно для работы - и это правильно. Дома нет никаких фаерволов и проблема не существет.

Кроме того, HTTP - это "hyper _TEXT_ transfer protocol". Для других задач существуют другие протоколы, лучше подходящие для решения задачи. Если нет стандартных - пишется custom протокол. А здесь предлагается писать custom протокол, да ещё пускать его поверх чего-то другого.
Ну ничего не вижу, кроме оверхеда....

2Dimentiy> Файерволы необходимы так же как и замки в дверях и это реальность. А масса народа работает вообще за прокси (под такими провайдерами как AOL и др, т.е. большая часть юзеров в штатах). Допустим я пишу любую П2П аппликацию (Возьмём простой случай: сетевая игра или веб-телефон или любая коммуникация. Мы с тобой должны иметь 2-х стороннюю связь. TCP/IP не пойдёт - файервол провайдера не пропустит ничего кроме HTTP, да ещё иногда и РОST запросы будет резать - если больше положенного максимума (товарищ мой в японию из за этого ездил - везде работает, а у них - обрывается (bug у тебя типа говорят): оказалось япошки максимальный размер для поста меньше его мессаги сделали). ОК, режу я стрим на куски и посылаю HTTP постами тебе, а ты - мне (аппликация симметричная - оба клиента являются одновременно и HTTP серверами). (IP мы могли бы обменяться и по телефону, хотя бывает и хуже - динамически выделяемый IP на каждый запрос - не знаю что за протокол, но видел в логах). ... Если бы не было прокси (физически нет доступа к другой стороне).

Традиционное решение - ставить сервак со статическим IP (outside) и всё пропускать через него. А если мы гоняем стримы - то этот сервак обойдётся в большую копеечку (и нетворк к нему подходящий и железо). Он всегда будет узким местом. И вообще - если оба мы сидим в Рязани (под разными провайдерами, за прокси или один из нас - из конторы, где, ессно фаервол) - зачем гонять столько даты через сервак который стоит в штатах?

Нам нужен GENERAL-PURPOSE RELAY SERVER - где-то по-близости, желательно сразу-же за нашими сетями - едакая коммутационная станция ("Барышня, соедините пажалста..."). И если в рязани есть хоть один такой (не связанный с аппликацией общего назначения коммутатор) - весь траффик не выйдет за пределы.

Есть более масштабные проекты: использовать процессорное время юзеровских машин (глобальный супер-компьютер и пр) - ведь сервера со статическими IP - это верхняя часть айсберга интернета. И это уже работает давно, правда с custom протоколами (юзеровские машины работают по ночам, может скоро и услуга такая появится - процессорное время продать) - JXTA предлагает стандартизовать это.

И ещё есть кое-какие аспекты (всего не опишешь ;-)

Я тоже бы предпочёл custom протокол: за несколько дней - и аппликация готова: открыл 2 сокета и пиши в сокет то что надо (что в голову придёт). На деле начинается: в одной и той же компании сервера в разных местах, на разных сетях, их надо интегрировать да порой и балансировать/синхронизировать. В больших проектах боятся custom - нужны стандарты, чтобы обезопаситься и мочь поменять подрядчика в любой момент и иметь пусть более тормозное решение (железки просто докупить) но максимально простое, максимально стандартное а главное - масштабируемое (а последнее - достаточно сложно - если from scratch)

Файервол это не замок на двери...

... это металло-дерево-пласмассо-искатель в общем подъезде. Проблемма должна решаться администратором на клиентах. Не хрен туда всякую фигню ставить.

Нет -- ну, конечно, если всюду стоят M$ Win 95 или у всех пользователей административные права... Но не проще ли в это случае задуматься о IT policy а не о файерволах?

>это металло-дерево-пласмассо-искатель в общем подъезде

скорее - это камера в подъезде (одна камера - над _одной_ дверью), что конечно же необходимо для секурности. Потом другого выхода нет: VPN одна за другой, на рутерах NAT, где как минимум простейший ipfadm/ipchains/iptables-басед фаервол стоит (А если серьёзно подходить - так и прокси д.б. + кэширование). На открытие дополнительных портов никто не пойдёт да это и не обсуждается (данность - это открытый 80 где и HTTP валидность, а иногда и максимальный размер и в некоторых случаях - даже некоторые имена домейнов в хедере не пропускаются). То есть ХТТП - единственный прозрачный канал - если в реале.

> или у всех пользователей административные права...

Насчёт юзеров - их никто не в силах контролировать (в чём разница - если и обычные права? Разве что систему (на клиент-машинах) не сломают так быстро). Если мы уж заговорили о необходимости/достаточности файервола (что офтопик вообще)то последний прежде всего нужен не против внутренних, а против внешних врагов (ну и за своими следить: куда ходють, что пересылають ;-) Потом - прокси - это уже для других целей.

Anode

2Anode:

> TCP/IP не пойдёт - файервол провайдера не пропустит ничего кроме
> HTTP, да ещё иногда и РОST запросы будет резать

Честно говоря, не видел таких провайдеров :) Это что-то совсем дикое. Провайдер предоставляет IP и считает трафик. Какие фаерволы?
Ну допустим, что всё именно так как написано. JXTA это решает, все p2p аппликации стали работать over JXTA.

Что будет следующим шагом? Фаерволы будут резать JXTA :-) С какой целью? С той же, с какой сейчас режут не-HTTP (если где-то режут. Это кто же такую услугу купит! :) ).
В сухом остатке имеем только overhead :-)

Вернёмся к (российским) реалиям. Возьмём типичную контору. Выход в сеть организован через какой-нибудь squid (например). Теперь сравним работу приложения напрямую и over http. Напрямую - либо сервис работает, либо нет. Через прокси - а кто знает, что сделает прокси с http-запросом? И получим ли мы именно то, что просили?

> Я тоже бы предпочёл custom протокол: за несколько дней - и
> аппликация готова: открыл 2 сокета и пиши в сокет то что надо (что
> в голову придёт). На деле начинается: в одной и той же компании
> сервера в разных местах, на разных сетях, их надо интегрировать да
> порой и балансировать/синхронизировать.

Простите, а что, http не надо балансировать/синхронизировать? Такой же точно протокол, только более распространённый :)
Если же Вы о том, что JXTA будет за нас балансировать нагрузку - то вот тут по-моему будет плохо. Потому что чтобы что-то синхронизировать, надо знать, _ЧТО_ синхронизировать. А транспортный уровень не должен этого знать. Если же знает - это фигня какая-то получается. И в плане секурности тоже.

Disclaimer: Про JXTA я не читал и может действительно чего-то не понимаю. Как раз хочется понять, стоит ли читать :)

> В больших проектах боятся custom - нужны стандарты,

Не вижу отличия RFCxxxx от _хорошей_ внутренней документации. Де факто. Хотя стандарты конечно нужны, главный вопрос - _какие_ стандарты.
В любом случае главное - характер передаваемой информации, а не транспортный уровень.

2 Dimentiy>

Ты пытаешься исходить из здравого смысла и наиболее оптимального метода (насчёт оверхеда, сложности итд - я с тобой и не спорю), рельность же, то что уже существует - всегда далеко от того что-бы мы хотели ведеть, не правда-ли? А реальность такова: Провайдер не хочет чтобы его сети, IP его паствы (_его_ IP в конце концов) были постоянными источниками взломов чужих сетей. А учитывая что средний юзеровский компьютер - это хуже помойки (под виндой конечно) со всеми мыслимыми открытыми портами и запущенными сервисами, где экзешники и activex контроли сгружаются ежедневно отовсюду, где вирусы (те, о которых в курсе антивирус, установленный при покупке компьютера год назад) деактивируются на регулярной основе (в лучшем случае), то провайдер будет закрывать всё что может и логить максимум путём постановки фаервола (если гоняют музыку и фильмы - не будешь же ты tcpdump или весь стрим дублировать ;-), а пересобрать всё на логгирующем рутере - это в общем простое копирование с буферизацией - ничто по сравнению с удобством всё иметь в одном логе.

Что будет следующим шагом? Фаерволы будут резать JXTA>

Этот вопрос я тоже задавал (можно экстраполировать до JXTA2 в более далёком будущем для обходов тех фаерволов и ad infinitum), потом кто-то рассказал что мол уже были попытки не пропускать file-sharing трафик одно время, но юзера деньги за это и платят (музыку и фильмы на шару качать), потом - не было ведь проблемы вывести всё на HTTP уровень, ну и от этого отказались мол.

Через прокси - а кто знает, что сделает прокси с http-запросом? И получим ли мы именно то, что просили?>

Это реальность также, и насколько я понимаю (поправьте если не так) - прокси ставятся для 2 целей: скрыть юзера, т.е. для секурити и для облегчения трафика и уменьшения response time (кэш), а уж проблема кэша - это извечная проблема во всех компутерных областях ;-)

балансировать/синхронизировать>

под балансированием/синхронизацией я имел в виду не столько routing (да ты прав: ведь JXTA занимается и транспортом и напоминает IP в этом смысле, только уже поверх HTTP и не только поверх него кстати + многим чем другим), сколько другую весчь: publishing. Стандартная архитектура: load-balancer + куча клонов аpplication серверов, которые должны синхронизоваться + DB сзади. Один из узких мест - load-balancer и его сеть и подходы к нему (он д.б. один, т.к. держит state (sticky sessions), значит даже если middle-tier и масштабируем да и при очень натянутом предположении что базы масштабируются ("сферические кони в вакууме" - там всё опять повторяется) - на самом деле всё несколько искуственно и пришло эволюционным путём от традиционной клиент-сервер модели. На самом деле - всё уже было: DNS. JXTA хочет построить недетерминистическую сеть (без нужды в DNS): есть только пиры и ID (cell-phone или POS-терминал, не имеющие IP - тоже пиры). И определяются группы над пирами (группы могут пересекаться). Мы шлём мессаги (или пайпы) либо пирам либо группам. Но для тех аппликаций где надо синхронизировать состояние как транзакция - нет проблем: имплементируется как надо, ты ведь знаешь всех пиров по ID. Ты просто не думаешь о транспорте. Параллель такую вижу: IP пакет -> JXTA мессага; TCP stream -> JXTA pipе.

Disclaimer> Я тоже ей глубоко не занимался, но очень любопытные идеи. Я думаю что и для практического применения и немного подкрутив там (использовав subset её, м.б. - всего один протокол из семи для начала) - могло бы что-то получиться и в приложении к рельным вещам.

Не вижу отличия RFCxxxx от _хорошей_ внутренней документации. > для покупателя - RFC - это гарантия

1)он _complete_ на текущий момент и скорее всего даже вся д.Васина контора не настолько крута чтобы всё до мелочей так продумать (д.Вася против всего мира)- включая будущие задачи; 2)есть наверняка тулы где-то уже проверяющие стандарт на compatibility и completeness в автоматическом режиме; 3)есть масса спецов с которыми можно посоветоваться (за спиной у д.Васи); В будущем можно будет также найти готовых спецов без траты на обучение; 4)что это доказанный индустрией и работающий реально стандарт и его не накалывает дядя Вася который лепит из себя такого-же гения как и все Васины конкуренты (никто же не лезет в код, да если и полезет что он там увидит?) Пожалуй главное - не зависеть от д.Васиной конторы;

В любом случае главное - характер передаваемой информации> не спорю

Anode

Ну в общем, логично :)