Burlap - разве не поверх HTTP работает?
в таком случае какой смысл его использовать? все-таки soap - это стандарт

Цитата(Souljah @ 15.9.2005, 18:36)

Burlap - разве не поверх HTTP работает?

Именно так, поверх.

Цитата(Souljah @ 15.9.2005, 18:36)

в таком случае какой смысл его использовать?

Простите, не уловил логики. Потому и использовать, что он позволяет решить заданную задачу: организовать взаимодействие серверов в ситуации, когда единственным имеющимся в наличии транспортом является HTTP.

Цитата(Souljah @ 15.9.2005, 18:36)

все-таки soap - это стандарт

Ну почему все так зациклены на этих стандартах? Главная выгода от использования стандарта - в возможности взаимодействия внешних компонентов, написанных под этот же стандарт. В каких-то случаях - да, это оправданное решение. В случае же полностью доморощенных (home-grown) комонентов выгоды от использования более "легкой" технологии ремоутинга вполне могут перевесить гипотетические выгоды от "стандартности".

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

Цитата(Stampede @ 15.9.2005, 22:58)

А я считаю, что если отталкиваться от специфики задачи, то существует еще более общий общий делитель: Java remoting over HTTP. Частными реализациями какового могут быть веб-сервисы, а могут быть и другие технологии, например Burlap/Hessian.

Burlap/Hessian и были первыми кандидатами на роль используемого протокола, только система будет интегрироваться с другими (с одной сразу, но написана она на Java), возможно клиенты системы будут написаны не на Java. Согласен, что на данный момент можно было все реализовать просто на чем-нибудь Java-зависимом и дорабатывать потом по мере необходимости, просто сразу захотелось универсальности, на всякий случай.

Чем дольше думаю, тем больше склоняюсь к идее применить все сразу. Если с сервером взаимодействует клиентское приложение, то приходится обмениваться довольно сложными структурами данных. Правда, вероятность того, что клиентские приложения будут написаны только на Java - 99%.

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

Stampede, спасибо. Заставил задуматься.

Цитата с http://www.caucho.com/:

Цитата

Hessian now includes Java, PHP, Python, C++, and C# implementations.

Так что и проблема кроссплатформенности в какой-то степени решается.

Stampede, мне кажется, что ты недооцениваешь роль веб-сервисов. Изначально основное их преимущество заключается в том, что они позволяют использовать в программировании приёмы интеграции Информационных Систем - и именно это является архитектурным ядром SOA.
В вопросе веб-сервисов достигнута совместимость ПО, которое можно писать на практически всех известных языках и платформах, главным образом - систем, написанных на .NET и J2EE между собой, чего ранее не было сделано в отношении CORBA.

Старые решения на допотопных и малораспространённых сейчас языках типа COBOL`а, Фортрана, можно обернуть в веб-сервис и тем самым удобно вплести в современную систему, работая с ним из любого языка.

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

Я убеждён, что у SOA огромный экономический потенциал и большое будущее.

С твоими же рассуждениями о том, что

Цитата(Stampede @ 15.9.2005, 18:59)

Ну почему все так зациклены на этих стандартах? Главная выгода от использования стандарта - в возможности взаимодействия внешних компонентов, написанных под этот же стандарт. В каких-то случаях - да, это оправданное решение. В случае же полностью доморощенных (home-grown) комонентов выгоды от использования более "легкой" технологии ремоутинга вполне могут перевесить гипотетические выгоды от "стандартности".

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

Иногда, когда бюджет очень маленький и задача очень специфическая, приходится писать что-то совершенно бесполезное для других целей - но по возможности этого следует как можно сильнее избегать, ИМХО, ибо стратегического толку от этого мало. Если мне приходится это делать часто - я начинаю подумывать о смене работы, ибо это - бесперспективняк, топтание на месте в плане профессионального роста.

Се ля ви, я тебе скажу как родному. Ты знаешь, как я тебя уважаю, но я тебе скажу, Шура, ты - ...

Нет, не так... Понимаешь... Про то, какая крутая штука эти веб-сервисы я могу прочитать во всяких гламурных журналах для ИТ-начальников, где все изложено на уровне, доступном для понимания именно этой публики. Но мы-то здесь - как раз те самые ребята, которые все это делают своими руками! Зачем же нас-то кормить дешевыми декларациями.

Почему декларациями? Потому что ну не работает, не работает SOAP-интероперабельность в жизни. Пока дело касается плоских типов и простейших структур - да, работает, но дальше - нет. Но ведь для интеграции разнородных приложений SOAP - не единственный выход. Люди испокон веков обменивались данными в форматах XML; фактически в любой прикладной области уже сложились свои стандарты этих форматов. И все прекрасно работает.

Что нового приносит поверх этого технология веб сервисов? Пшик она приносит. Пустышку. Ложное чувство синхронности RPC и псевдо-удобство автогенерации интерфейсного кода.

Вот ты говоришь типа система на фортране. А у тебя система на Java со сложными объектами. Ну и как ты смапишь свои объекты на фортрановские типы? Никак не смапишь, будешь все приводить к уровню наибольшей общей понимаемости - то есть обратно к строкам и примитивам. Вот в этом и есть весь SOAP.

А "резинщики", всесто того чтобы разглагольствовать об интерабельности, просто молча взяли и сделали в этом направлении практический шаг: написали реализации для других языков (tux, спасибо за информацию - это действительно грандиозная новость). И вот это истинная интероперабельность.

(обращаясь ко всем) Товарищи, я вас очень прошу, не путайте теплое с мягким. Есть задача ремоутинга, и есть задача интеграции, и это две разные вещи. Вы пытаетесь для обеих задач использовать один механизм, веб сервисы, а он на самом деле не является наилучшим выбором ни для одного, ни для другого.

И еще: не молитесь на стандарты, ибо сказно "не сотвори себе кумира". Помните, что стандарты создаются теоретиками!

У меня пока все

Stampede, хм... Ну что ж, заставил усомниться.
Я сейчас только начинаю разбираться с веб-сервисами, посмотрю... возможно, действительно фигня, хотя на теоретическом уровне концепция кажется здравой. В любом случае маркетинг там явно опережает функциональность, чуваки денег хотят бессовестно срубить.

Но точно так же раньше говорили и про Java - типа маркетинг, мода! Не майтесь дурью, учите С++, он быстрее, надёжнее, а с вас просто денег хотят поиметь хитрые Sun`овцы.

Кароче ладно, я пока в сомнениях... Когда определюсь - напишу

Это сообщение отредактировал(а) Се ля ви - 17.9.2005, 02:02

Се ля ви, я тебе предлагаю в порядке отрезвляющего эксперимента проделать простую вещь:

1. Возьми любой распределенный компонент, который у тебя есть (из реального приложения, чтобы долго не страдать), и сделай его доступным через Axis. Вернее нет, не любой, а такой, который бы принимал/возвращал сложные типы: чтобы там были коллекции, графы зависимых объектов и пр.

2. Попробуй написать к нему простейшего .Net клиента.

3. Расскажи, что получилось.

Я тебе на полном серьезе говорю, вот просто поезжайте в Киев сделай - и всё. А потом продолжим разговор об интероперабельности

The Axis2 core supports both RPC-style and message-style interactions based on the one-way messaging model.

http://www.jaxmag.com/itr/online_artikel/p...nodeid,147.html


В общем я тут покопался с Axis2 - вроде то что тебе надо. - тут написал как делать - http://forum.vingrad.ru/index.php?showtopic=102294  

Это сообщение отредактировал(а) x4444 - 29.6.2006, 20:00

Скажи пожалуйста какие функции сервера в данном проекте.

чегойто не открывается страничка... 

seth, подойди к этой проблеме творчески 
http://www.caucho.com/resin-3.0/protocols/burlap.xtp

я так понимаю что бурлап входит в резин? т.е. отдельно от резина его низзя использовать? (например в томкате)