WCF 4.0 vs Java what?
От: vladimir.vladimirovich США  
Дата: 04.06.10 19:11
Оценка:
Вот в лагере додНЕда есть прекрасная штука — WCF, от которой волосы становятся мягкими и шолковистыми даже на спине. Сейчас вышла 4 версия, которая фигурально выражаясь позволяет вообще все, что нужно сделать через себя и очень просто, а вот есть ли в стане Java что-нибудь настолько же хорошее?
Re: WCF 4.0 vs Java what?
От: Roman Odaisky Украина  
Дата: 04.06.10 20:33
Оценка:
WCF не нужна (©)
Java не нужна (©)

А как в WCF задавать асинхронные операции, коллбеками или yield return?
До последнего не верил в пирамиду Лебедева.
Re[2]: WCF 4.0 vs Java what?
От: vladimir.vladimirovich США  
Дата: 04.06.10 21:03
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>WCF не нужна (©)

RO>Java не нужна (©)
RO>А как в WCF задавать асинхронные операции, коллбеками или yield return?

А вы с какой целью интересуетесь?
Re: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 04.06.10 21:20
Оценка:
Здравствуйте, vladimir.vladimirovich, Вы писали:

VV>Вот в лагере додНЕда есть прекрасная штука — WCF, от которой волосы становятся мягкими и шолковистыми даже на спине. Сейчас вышла 4 версия, которая фигурально выражаясь позволяет вообще все, что нужно сделать через себя и очень просто, а вот есть ли в стане Java что-нибудь настолько же хорошее?

Я долго на него смотрел и не мог понять: а нафиг он нужен-то?

Аналоги WCF — это Spring + система экспортёров + JMS. Каждая часть там занимается своей работой.
Sapienti sat!
Re[2]: WCF 4.0 vs Java what?
От: vladimir.vladimirovich США  
Дата: 04.06.10 21:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Аналоги WCF — это Spring + система экспортёров + JMS. Каждая часть там занимается своей работой.


Spring и JMS — это про то, как доставить что-то куда-то, А wcf — это еще и что сделать с этим чем-то. Уровень абстракции выше.
Re[2]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.10 22:28
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>WCF не нужна (©)

RO>Java не нужна (©)

RO>А как в WCF задавать асинхронные операции, коллбеками или yield return?

Подобное поведение реализуется интеграцией WF4 и WCF.

WF описывает высокоуровневый сценарий, который может полностью выгружаться, например при длительных операциях, и "просыпаться" на другой машине при необходимости. В сценарий WF можно воткнуть WCF действия типа "прием запроса от endpoint-а" и "отдача ответа в endpoint".

А также в RC находится Window Server Appfabric, которая изкаропки дает готовую среду для хостинга таких процессов на IIS (она и так доступна, но настраивать надо), средства мониторинга и трассировки.

А также в разработке DSL на базе M (Oslo), который позволит эти самые процессы описывать в виде текста.
Re[3]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 04.06.10 22:40
Оценка:
Здравствуйте, vladimir.vladimirovich, Вы писали:

C>>Аналоги WCF — это Spring + система экспортёров + JMS. Каждая часть там занимается своей работой.

VV>Spring и JMS — это про то, как доставить что-то куда-то, А wcf — это еще и что сделать с этим чем-то. Уровень абстракции выше.
Это не уровень абстракции, а неправильный дизайн...

К сожалению, в Java оно тоже присутствует: http://www.mulesoft.com/mule-data-integrator-mapping-transformation

Я так и не понял в каких случаях можно архитектора не расстреливать за использование подобных помоек...
Sapienti sat!
Re[3]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 04.06.10 22:43
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>WF описывает высокоуровневый сценарий, который может полностью выгружаться, например при длительных операциях, и "просыпаться" на другой машине при необходимости. В сценарий WF можно воткнуть WCF действия типа "прием запроса от endpoint-а" и "отдача ответа в endpoint".

Это умеет любой business process execution движок... И WCF тут играет роль банального локатора + RPC.

Более интересен пример оркестрации с распределёнными транзакциями и контекстом безопасности. Точнее то, насколько всё оно угрёбищно сделано ВЕЗДЕ.
Sapienti sat!
Re[4]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.10 23:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


G>>WF описывает высокоуровневый сценарий, который может полностью выгружаться, например при длительных операциях, и "просыпаться" на другой машине при необходимости. В сценарий WF можно воткнуть WCF действия типа "прием запроса от endpoint-а" и "отдача ответа в endpoint".

C>Это умеет любой business process execution движок...
а)их не так много
б)WF + WCF можно масштабировать в любую сторону

C>И WCF тут играет роль банального локатора + RPC.

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

C>Более интересен пример оркестрации с распределёнными транзакциями и контекстом безопасности. Точнее то, насколько всё оно угрёбищно сделано ВЕЗДЕ.

С безопасностью еще нормально, а с транзакциями вообще везде угребищно. ИМХО распределенные транзакции — вообще плохая идея.
Re[4]: WCF 4.0 vs Java what?
От: Ночной Смотрящий Россия  
Дата: 05.06.10 06:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Это умеет любой business process execution движок... И WCF тут играет роль банального локатора + RPC.


И очень надеюсь, что никакой другой роли он никогда играть не будет. WCF это только и исключительно коммуникационный слой, а не все мухи в котлетах ака CORBA.
Re[5]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 05.06.10 13:58
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Это умеет любой business process execution движок... И WCF тут играет роль банального локатора + RPC.

НС>И очень надеюсь, что никакой другой роли он никогда играть не будет. WCF это только и исключительно коммуникационный слой, а не все мухи в котлетах ака CORBA.
Поздно. В WCF уже входят распределённые транзакции и прочая гадость.
Sapienti sat!
Re[5]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 05.06.10 14:03
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

C>>Это умеет любой business process execution движок...

G>а)их не так много
А зачем много-то?

G>б)WF + WCF можно масштабировать в любую сторону

И не он один.

C>>И WCF тут играет роль банального локатора + RPC.

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

Модель программирования для REST-ful web-сервисов и CORBA-style RPC будет отличаться просто из-за своих фундаментальных основ.
Sapienti sat!
Re[3]: WCF 4.0 vs Java what?
От: henson Россия http://www.njt-rails.com
Дата: 05.06.10 14:21
Оценка:
Здравствуйте, vladimir.vladimirovich, Вы писали:

VV>Здравствуйте, Roman Odaisky, Вы писали:


RO>>WCF не нужна (©)

RO>>Java не нужна (©)
RO>>А как в WCF задавать асинхронные операции, коллбеками или yield return?

VV>А вы с какой целью интересуетесь?


Очевидно это провокация
Re[4]: WCF 4.0 vs Java what?
От: Roman Odaisky Украина  
Дата: 05.06.10 17:52
Оценка:
Здравствуйте, henson, Вы писали:

RO>>>А как в WCF задавать асинхронные операции, коллбеками или yield return?

VV>>А вы с какой целью интересуетесь?
H>Очевидно это провокация :))

А с какой целью можно задавать такие вопросы в этом форуме? Можно будет поругать WCF за синтаксический оверхед.
До последнего не верил в пирамиду Лебедева.
Re[6]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.10 17:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


C>>>Это умеет любой business process execution движок...

G>>а)их не так много
C>А зачем много-то?
Ну для того чтобы говорить что любой <подставить сюда название> это умеет. Когда "любых" единицы, причем половина сильно платные, то такие слова малый вес имеют.

G>>б)WF + WCF можно масштабировать в любую сторону

C>И не он один.
И какие аналоги связке WF + WCF в мире жабы есть?
Так чтобы:
1)Единая модель программирования и настройки сервисов поверх любых каналов
2)Transport-level и message level serurity
3)Workflow c возможностью "засыпания" в backend.
4)Какой-нить универсальный хостинг для всего этого, с широкими возможностями управления и мониторинга
5)Чтобы API этого дела не был "вирусным", те чтобы не проникал во все аспекты работы приложения (этим например грешит biztalk)

C>>>И WCF тут играет роль банального локатора + RPC.

G>>WCF это вообще абстракция над каналами связи. Предоставляет единую модель программирования и конфигурации для любых средств связи между приложениями.
C>Ой, ну не надо сказок рассказывать только. "Сетевая прозрачность", "независимость от транспорта" — это уже всё было в начале 90-х. На практике, оно всё один фиг непрозрачное и зависимое.
Не хочу спорить о вкусе устриц с человеком, который их не ел.

C>Модель программирования для REST-ful web-сервисов и CORBA-style RPC будет отличаться просто из-за своих фундаментальных основ.

Да ну? Если я могу реализовать rest-api на сервере с помощью классов с методами, которые однозначно мапятся на урлы, то точно также можно реализовать и клиенты. С помощью этих же классов я могу выставить WS-* вебсервис.
Так что никакие "фундаментальные основы" не мешают использовать абсолютно одинаковую модель как на сервере, так и на клиенте.
Re[6]: WCF 4.0 vs Java what?
От: Ночной Смотрящий Россия  
Дата: 05.06.10 20:02
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Поздно. В WCF уже входят распределённые транзакции и прочая гадость.


Не входят. Есть behavior взаимодействия с DTC, который вполне откручивается за ненадобностью.
Re[2]: WCF 4.0 vs Java what?
От: Ночной Смотрящий Россия  
Дата: 05.06.10 20:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Аналоги WCF — это Spring + система экспортёров + JMS


Сильно, ничего не скажешь.
Re[3]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 05.06.10 22:28
Оценка: :)
Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Аналоги WCF — это Spring + система экспортёров + JMS

НС>Сильно, ничего не скажешь.
Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения.
Sapienti sat!
Re[7]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 05.06.10 22:57
Оценка:
Здравствуйте, gandjustas, Вы писали:

C>>А зачем много-то?

G>Ну для того чтобы говорить что любой <подставить сюда название> это умеет. Когда "любых" единицы, причем половина сильно платные, то такие слова малый вес имеют.
http://www.jboss.org/jbpm

G>>>б)WF + WCF можно масштабировать в любую сторону

C>>И не он один.
G>И какие аналоги связке WF + WCF в мире жабы есть?
G>Так чтобы:
G>1)Единая модель программирования и настройки сервисов поверх любых каналов
Mule — http://www.mulesoft.org/documentation/display/MULE2USER/Available+Transports

Ещё от Апача:
http://servicemix.apache.org/home.html
http://fusesource.com/products/enterprise-servicemix/

G>2)Transport-level и message level serurity

Это противоречивое требование с пунктом 1). Фиг у тебя будет message-level security поверх JSON. Если транспорт позволяет — может быть и то, и другое...

G>3)Workflow c возможностью "засыпания" в backend.

И Мул и ServiceMix/FUSE поддерживают подключаемые движки сценариев, чаще всего юзают JBoss BPM.

G>4)Какой-нить универсальный хостинг для всего этого, с широкими возможностями управления и мониторинга

Стандартный JEE. Управление — через JMX.

C>>Ой, ну не надо сказок рассказывать только. "Сетевая прозрачность", "независимость от транспорта" — это уже всё было в начале 90-х. На практике, оно всё один фиг непрозрачное и зависимое.

G>Не хочу спорить о вкусе устриц с человеком, который их не ел.
Я это "прозрачности" наелся уже до отвала... Уже изучил и тонкости распространения XA-транзакций и CAP-теорему и прочее.

C>>Модель программирования для REST-ful web-сервисов и CORBA-style RPC будет отличаться просто из-за своих фундаментальных основ.

G>Да ну? Если я могу реализовать rest-api на сервере с помощью классов с методами, которые однозначно мапятся на урлы, то точно также можно реализовать и клиенты. С помощью этих же классов я могу выставить WS-* вебсервис.
Да вот только в CORBA есть возможность давать удалённые ссылки. Т.е. я могу клиенту отдать объект, у которого поля — это ссылки на объекты на другом хосте. А ещё в CORBA есть возможность callback'ов. Т.е. вызовов с сервера на клиент. Как ты это будешь отображать в JSON-API, работаюшее поверх REST?

А ещё есть вопросы с типами данных. В JSON, к примеру, нет стандартного mapping'а для timestamp'ов с наносекундным разрешением. А ещё есть душевный стандарт ASN.1, там типы "последовательность" и "последовательность_из_строго_пяти_элементов" — это разные вещи. И если у тебя тип потеряется во время передачи (а он один фиг потеряется, у других форматов нет такого кретинизма) — результат не будет валидным для нужной схемы.

...и это только мои личные примеры...
Sapienti sat!
Re[8]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.10 23:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


C>>>А зачем много-то?

G>>Ну для того чтобы говорить что любой <подставить сюда название> это умеет. Когда "любых" единицы, причем половина сильно платные, то такие слова малый вес имеют.
C>http://www.jboss.org/jbpm
И что?

G>>>>б)WF + WCF можно масштабировать в любую сторону

C>>>И не он один.
G>>И какие аналоги связке WF + WCF в мире жабы есть?
G>>Так чтобы:
G>>1)Единая модель программирования и настройки сервисов поверх любых каналов
C>Mule — http://www.mulesoft.org/documentation/display/MULE2USER/Available+Transports
C>Ещё от Апача:
C>http://servicemix.apache.org/home.html
C>http://fusesource.com/products/enterprise-servicemix/

Это не то, это продукты enterprise уровня. В своем приложении такое не захостишь.

G>>2)Transport-level и message level serurity

C>Это противоречивое требование с пунктом 1). Фиг у тебя будет message-level security поверх JSON. Если транспорт позволяет — может быть и то, и другое...
Все виды security должны работать если поддерживаются каналом.

G>>3)Workflow c возможностью "засыпания" в backend.

C>И Мул и ServiceMix/FUSE поддерживают подключаемые движки сценариев, чаще всего юзают JBoss BPM.
См выше.
Мул кстати платный.

G>>4)Какой-нить универсальный хостинг для всего этого, с широкими возможностями управления и мониторинга

C>Стандартный JEE. Управление — через JMX.
Не, я хочу красивую консольку.


C>>>Модель программирования для REST-ful web-сервисов и CORBA-style RPC будет отличаться просто из-за своих фундаментальных основ.

G>>Да ну? Если я могу реализовать rest-api на сервере с помощью классов с методами, которые однозначно мапятся на урлы, то точно также можно реализовать и клиенты. С помощью этих же классов я могу выставить WS-* вебсервис.
C>Да вот только в CORBA есть возможность давать удалённые ссылки. Т.е. я могу клиенту отдать объект, у которого поля — это ссылки на объекты на другом хосте.
WCF — фреймворк, он не знает об "объектах". С помощью конфига можно сделать похожим на remote objects, но это крайне не рекомендуется.
А ссылки в нем — обычные URI

C>А ещё в CORBA есть возможность callback'ов. Т.е. вызовов с сервера на клиент. Как ты это будешь отображать в JSON-API, работаюшее поверх REST?

Никак, просто контракт, не поддерживающий callback. Хотя никто не мешает тот же JSON гонять по net.tcp с callback.

C>А ещё есть вопросы с типами данных. В JSON, к примеру, нет стандартного mapping'а для timestamp'ов с наносекундным разрешением. А ещё есть душевный стандарт ASN.1, там типы "последовательность" и "последовательность_из_строго_пяти_элементов" — это разные вещи. И если у тебя тип потеряется во время передачи (а он один фиг потеряется, у других форматов нет такого кретинизма) — результат не будет валидным для нужной схемы.

Это ты о чем? На обоих концах .NET приложение — пох что там потеряется, на сервере .NET, на клиенте javascript — тоже отлично работает.
Re[4]: WCF 4.0 vs Java what?
От: vladimir.vladimirovich США  
Дата: 06.06.10 00:17
Оценка:
Здравствуйте, henson, Вы писали:

VV>>А вы с какой целью интересуетесь?

H>Очевидно это провокация

Я так и подумал.
Re[4]: WCF 4.0 vs Java what?
От: vladimir.vladimirovich США  
Дата: 06.06.10 00:19
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения.


С помощью TCP вообще можно то же самое сделать. ага...
Re[9]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 01:12
Оценка:
Здравствуйте, gandjustas, Вы писали:

C>>Mule — http://www.mulesoft.org/documentation/display/MULE2USER/Available+Transports

C>>Ещё от Апача:
C>>http://servicemix.apache.org/home.html
C>>http://fusesource.com/products/enterprise-servicemix/
G>Это не то, это продукты enterprise уровня. В своем приложении такое не захостишь.
Эээ... А кто мешает-то? Mule — это что-то около 5Мб jar-ников в не очень навороченной конфигурации. Тупо подключаешь их через Spring и вперёд с песней.

G>>>2)Transport-level и message level serurity

C>>Это противоречивое требование с пунктом 1). Фиг у тебя будет message-level security поверх JSON. Если транспорт позволяет — может быть и то, и другое...
G>Все виды security должны работать если поддерживаются каналом.
Как ты подпишешь сообщение JSON?

Для XML это делается без проблем (http://java.sun.com/webservices/xmldsig/index.jsp), а вот для JSON — увы.

G>>>3)Workflow c возможностью "засыпания" в backend.

C>>И Мул и ServiceMix/FUSE поддерживают подключаемые движки сценариев, чаще всего юзают JBoss BPM.
G>См выше.
G>Мул кстати платный.
Кстати нет: http://www.mulesoft.org/mule-community-vs-mule-enterprise — у них определённая часть платная только.

G>>>4)Какой-нить универсальный хостинг для всего этого, с широкими возможностями управления и мониторинга

C>>Стандартный JEE. Управление — через JMX.
G>Не, я хочу красивую консольку.
Умм... А что в JMX некрасивого? Это просто стандарт на обобщённую систему управления и мониторинга.

А клиентом к ней может быть как гламурное приложение: http://sourceforge.net/dbimage.php?id=8061 , так и утиллита командной строки: https://launchpad.net/jmxterm

Это просто для .NET нет нормального обобщённого API для мониторинга (WMI must die).

C>>Да вот только в CORBA есть возможность давать удалённые ссылки. Т.е. я могу клиенту отдать объект, у которого поля — это ссылки на объекты на другом хосте.

G>WCF — фреймворк, он не знает об "объектах". С помощью конфига можно сделать похожим на remote objects, но это крайне не рекомендуется.
G>А ссылки в нем — обычные URI
Добавь сюда гетерогенные сети и станет интересно

C>>А ещё в CORBA есть возможность callback'ов. Т.е. вызовов с сервера на клиент. Как ты это будешь отображать в JSON-API, работаюшее поверх REST?

G>Никак, просто контракт, не поддерживающий callback. Хотя никто не мешает тот же JSON гонять по net.tcp с callback.
Так вот в том-то и проблема.

C>>А ещё есть вопросы с типами данных. В JSON, к примеру, нет стандартного mapping'а для timestamp'ов с наносекундным разрешением. А ещё есть душевный стандарт ASN.1, там типы "последовательность" и "последовательность_из_строго_пяти_элементов" — это разные вещи. И если у тебя тип потеряется во время передачи (а он один фиг потеряется, у других форматов нет такого кретинизма) — результат не будет валидным для нужной схемы.

G>Это ты о чем? На обоих концах .NET приложение — пох что там потеряется, на сервере .NET, на клиенте javascript — тоже отлично работает.
Endpoint может быть не .NET-овым. И WCF предоставляет возможности роутинга сообщений и проксики. И там оно всё начинается...
Sapienti sat!
Re[5]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 04:03
Оценка:
Здравствуйте, vladimir.vladimirovich, Вы писали:

C>>Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения.

VV>С помощью TCP вообще можно то же самое сделать. ага...
Ты мне задачу опиши, а я расскажу как на Java сделать.
Sapienti sat!
Re[10]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.06.10 08:14
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


C>>>Mule — http://www.mulesoft.org/documentation/display/MULE2USER/Available+Transports

C>>>Ещё от Апача:
C>>>http://servicemix.apache.org/home.html
C>>>http://fusesource.com/products/enterprise-servicemix/
G>>Это не то, это продукты enterprise уровня. В своем приложении такое не захостишь.
C>Эээ... А кто мешает-то? Mule — это что-то около 5Мб jar-ников в не очень навороченной конфигурации. Тупо подключаешь их через Spring и вперёд с песней.
Примеры есть?

G>>>>2)Transport-level и message level serurity

C>>>Это противоречивое требование с пунктом 1). Фиг у тебя будет message-level security поверх JSON. Если транспорт позволяет — может быть и то, и другое...
G>>Все виды security должны работать если поддерживаются каналом.
C>Как ты подпишешь сообщение JSON?
Буду использовать HTTPS, если уже очень надо, то можно расширение протокола http забабахать, хотя смысла в этом не вижу.
Так или иначе логика сервера и клиента не поменяется.


G>>>>3)Workflow c возможностью "засыпания" в backend.

C>>>И Мул и ServiceMix/FUSE поддерживают подключаемые движки сценариев, чаще всего юзают JBoss BPM.
G>>См выше.
G>>Мул кстати платный.
C>Кстати нет: http://www.mulesoft.org/mule-community-vs-mule-enterprise — у них определённая часть платная только.
Community Edition — Evaluation or pre-production use...
Для продакшена — платный.


G>>>>4)Какой-нить универсальный хостинг для всего этого, с широкими возможностями управления и мониторинга

C>>>Стандартный JEE. Управление — через JMX.
G>>Не, я хочу красивую консольку.
C>Умм... А что в JMX некрасивого? Это просто стандарт на обобщённую систему управления и мониторинга.
C>А клиентом к ней может быть как гламурное приложение: http://sourceforge.net/dbimage.php?id=8061 , так и утиллита командной строки: https://launchpad.net/jmxterm
C>Это просто для .NET нет нормального обобщённого API для мониторинга (WMI must die).
WMI позволяет управлять и мониторить все, а JMX — то что на жабе написно, кагбе разная мощность технологий.

C>>>Да вот только в CORBA есть возможность давать удалённые ссылки. Т.е. я могу клиенту отдать объект, у которого поля — это ссылки на объекты на другом хосте.

G>>WCF — фреймворк, он не знает об "объектах". С помощью конфига можно сделать похожим на remote objects, но это крайне не рекомендуется.
G>>А ссылки в нем — обычные URI
C>Добавь сюда гетерогенные сети и станет интересно
А какая разница?

C>>>А ещё в CORBA есть возможность callback'ов. Т.е. вызовов с сервера на клиент. Как ты это будешь отображать в JSON-API, работаюшее поверх REST?

G>>Никак, просто контракт, не поддерживающий callback. Хотя никто не мешает тот же JSON гонять по net.tcp с callback.
C>Так вот в том-то и проблема.
В чем? Пока клиенты json сервисов, а это на 99% javascript, не научится работать с callback, то смысла в таком решении нету.
Надо реальные проблемы решать, а не абстрактные.

C>>>А ещё есть вопросы с типами данных. В JSON, к примеру, нет стандартного mapping'а для timestamp'ов с наносекундным разрешением. А ещё есть душевный стандарт ASN.1, там типы "последовательность" и "последовательность_из_строго_пяти_элементов" — это разные вещи. И если у тебя тип потеряется во время передачи (а он один фиг потеряется, у других форматов нет такого кретинизма) — результат не будет валидным для нужной схемы.

G>>Это ты о чем? На обоих концах .NET приложение — пох что там потеряется, на сервере .NET, на клиенте javascript — тоже отлично работает.
C>Endpoint может быть не .NET-овым.
Если не .NET, значит js — см выше.

C>И WCF предоставляет возможности роутинга сообщений и проксики. И там оно всё начинается...

И что?
Re[6]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.06.10 09:15
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, vladimir.vladimirovich, Вы писали:


C>>>Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения.

VV>>С помощью TCP вообще можно то же самое сделать. ага...
C>Ты мне задачу опиши, а я расскажу как на Java сделать.

Вот отличный пример
http://msdn.microsoft.com/en-us/magazine/ff646977.aspx
Re[7]: WCF 4.0 vs Java what?
От: Roman Odaisky Украина  
Дата: 06.06.10 12:21
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Вот отличный пример

G>http://msdn.microsoft.com/en-us/magazine/ff646977.aspx

Я чего-то не пойму, или это десятка полтора строк, заодно в полностью асинхронном варианте?
@defer.inlineCallbacks
def xmlrpc_process_submission(self, submission):
    if should_reject(submission):
        defer.returnValue({ "result": "rejected" })
    if should_resubmit(submission):
        defer.returnValue({ "result": "resubmit" })
    for v in self.vendors:
        result = yield remote_call(v, submission)
        if result.success:
            break
    else:
        defer.returnValue({ "result": "unapproved" })
    yield save_to_db(result.whatever)
    defer.returnValue({ "result": "accepted" })

Модный GUI — конечно, хорошо, но три поставщика отдельными блоками вместо цикла наводят на мысль о том, что оно просто не умеет оформлять циклы. О замене программирования перетаскиванием блоков туда-сюда говорят уже давно, но ничего дельного пока не замечено.
До последнего не верил в пирамиду Лебедева.
Re[8]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.06.10 13:04
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, gandjustas, Вы писали:


G>>Вот отличный пример

G>>http://msdn.microsoft.com/en-us/magazine/ff646977.aspx

RO>Я чего-то не пойму, или это десятка полтора строк, заодно в полностью асинхронном варианте?

RO>
RO>@defer.inlineCallbacks
RO>def xmlrpc_process_submission(self, submission):
RO>    if should_reject(submission):
RO>        defer.returnValue({ "result": "rejected" })
RO>    if should_resubmit(submission):
RO>        defer.returnValue({ "result": "resubmit" })
RO>    for v in self.vendors:
RO>        result = yield remote_call(v, submission)
RO>        if result.success:
RO>            break
RO>    else:
RO>        defer.returnValue({ "result": "unapproved" })
RO>    yield save_to_db(result.whatever)
RO>    defer.returnValue({ "result": "accepted" })
RO>

1)Действие Ask vendor работает гораздо интереснее, чем один remote call, оно во время запроса у вендору умеет отвечать на запросы пользователя о состоянии процесса?
2)Я не очень в курсе на чем работает приведенный тобой код, но есть сомнения что все вызовы, входящие и исходящие, можно будет произвольно настраивать, в том числе в рантайме?
3)Приведенный тобой код умеет выгружаться в случае простаивания по какой-либо причине, переживет ли перезагрузку сервера?
4)Как отследить потом работу сервиса?
5)Как клиентский api выглядеть будет?

RO>Модный GUI — конечно, хорошо, но три поставщика отдельными блоками вместо цикла наводят на мысль о том, что оно просто не умеет оформлять циклы.

Цикл будет гораздо менее нагляден. Вообще цикл — плохой инструмент для декларативной разработки.

RO>О замене программирования перетаскиванием блоков туда-сюда говорят уже давно, но ничего дельного пока не замечено.

Наоборот, существует тенденция замены блоков\xml на DSL или скриптовые языки. В WF тоже такое есть, но по наглядности блоки со стрелочками покачто рулят.
Re[7]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 13:15
Оценка:
Здравствуйте, gandjustas, Вы писали:

C>>Ты мне задачу опиши, а я расскажу как на Java сделать.

G>Вот отличный пример
G>http://msdn.microsoft.com/en-us/magazine/ff646977.aspx
Только вот причём здесь WCF?..

http://www.infoq.com/articles/jboss-esb-jbpm
http://www.jboss.org/jbossesb/screens.html

Абсолютно стандартный use-case для ESB-систем.
Sapienti sat!
Re[4]: WCF 4.0 vs Java what?
От: Ночной Смотрящий Россия  
Дата: 06.06.10 13:27
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения.


В очередной раз убеждаюсь, что ты плохо представляешь себе предмет спора. Надергал какие то обрывки из статей, а остальное додумал. Нет, WCF это не Spring+JMS даже близко.
Re[8]: WCF 4.0 vs Java what?
От: Ночной Смотрящий Россия  
Дата: 06.06.10 13:27
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>...и это только мои личные примеры...


А теперь посчитай количество абрривеатур и технологий, которые ты в своем сообщении помянул.
Re[11]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 13:30
Оценка:
Здравствуйте, gandjustas, Вы писали:

C>>Эээ... А кто мешает-то? Mule — это что-то около 5Мб jar-ников в не очень навороченной конфигурации. Тупо подключаешь их через Spring и вперёд с песней.

G>Примеры есть?
Я так лично делал. Причём ещё с монитором распределённых транзакций (http://www.atomikos.com/). Всё полностью уместилось в 10Мб вместе с кучей дополнительных библиотек.

G>>>Все виды security должны работать если поддерживаются каналом.

C>>Как ты подпишешь сообщение JSON?
G>Буду использовать HTTPS, если уже очень надо, то можно расширение протокола http забабахать, хотя смысла в этом не вижу.
G>Так или иначе логика сервера и клиента не поменяется.
HTTPS — это канальный уровень, а не уровень сообщений. Вот XMLDSIG — это уровень сообщений, но не канальный.

G>>>Мул кстати платный.

C>>Кстати нет: http://www.mulesoft.org/mule-community-vs-mule-enterprise — у них определённая часть платная только.
G>Community Edition — Evaluation or pre-production use...
G>Для продакшена — платный.
Не, ну хватит бред нести.

Mule Community Edition доступен под http://en.wikipedia.org/wiki/Common_Public_Attribution_License , которая является weak copyleft-лицензией. Т.е. ты не обязан открывать исходный код своего приложения, но должен открыть исходный код Mule ESB и изменений в нём.

C>>Это просто для .NET нет нормального обобщённого API для мониторинга (WMI must die).

G>WMI позволяет управлять и мониторить все, а JMX — то что на жабе написно, кагбе разная мощность технологий.
Не всё. Мой Линуксовый сервер через WMI не получится мониторить, так же как и сетевой принтер и роутер.

Для общего мониторинга есть SNMP, с которым JMX стыкуется без проблем. Только нафиг это надо?

G>>>А ссылки в нем — обычные URI

C>>Добавь сюда гетерогенные сети и станет интересно
G>А какая разница?
Файрволы и всё такое.

G>>>Никак, просто контракт, не поддерживающий callback. Хотя никто не мешает тот же JSON гонять по net.tcp с callback.

C>>Так вот в том-то и проблема.
G>В чем? Пока клиенты json сервисов, а это на 99% javascript, не научится работать с callback, то смысла в таком решении нету.
G>Надо реальные проблемы решать, а не абстрактные.
Так проблема реальная. Пришлось делать Comet-подобный транспортный протокол.

G>>>Это ты о чем? На обоих концах .NET приложение — пох что там потеряется, на сервере .NET, на клиенте javascript — тоже отлично работает.

C>>Endpoint может быть не .NET-овым.
G>Если не .NET, значит js — см выше.
Вы можете выбрать машину любого цвета, при условии, что этот цвет — чёрный.

WCF стыкуется с кучей всего, по заявлением MS. А на практике...

C>>И WCF предоставляет возможности роутинга сообщений и проксики. И там оно всё начинается...

G>И что?
И то. Нету красоты.
Sapienti sat!
Re[5]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 13:32
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения.

НС>В очередной раз убеждаюсь, что ты плохо представляешь себе предмет спора. Надергал какие то обрывки из статей, а остальное додумал. Нет, WCF это не Spring+JMS даже близко.
Ну так объясни что же это такое?

Только примеры по самому WCF приводи, а не по WF.
Sapienti sat!
Re[9]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 13:32
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

C>>...и это только мои личные примеры...

НС>А теперь посчитай количество абрривеатур и технологий, которые ты в своем сообщении помянул.
И что? По сути возражений нет — иди лесом.
Sapienti sat!
Re[10]: WCF 4.0 vs Java what?
От: Ночной Смотрящий Россия  
Дата: 06.06.10 13:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

НС>>А теперь посчитай количество абрривеатур и технологий, которые ты в своем сообщении помянул.

C>И что?

Поясню. Любая практически задача может быть решена пачкой библиотек и рукопашным кодированием. Вопрос в том, насколько качественно и какой ценой. Чем больше разноплановых библиотек (особенно таких монстров как Spring) вовлечено в решение задачи, тем означенная цель менее достижима. Все просто.

C> По сути возражений нет — иди лесом.


Это по сути. Лесники, кстати, очень часто в баньке бывают. Меня вот ни разу не банили, а тебя?
Re[6]: WCF 4.0 vs Java what?
От: Ночной Смотрящий Россия  
Дата: 06.06.10 13:44
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Ну так объясни что же это такое?


Смысла не вижу тратить силы. Ты все равно никогда не слушаешь.
Re[11]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 14:40
Оценка: -1
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>А теперь посчитай количество абрривеатур и технологий, которые ты в своем сообщении помянул.

C>>И что?
НС>Поясню. Любая практически задача может быть решена пачкой библиотек и рукопашным кодированием. Вопрос в том, насколько качественно и какой ценой. Чем больше разноплановых библиотек (особенно таких монстров как Spring) вовлечено в решение задачи, тем означенная цель менее достижима. Все просто.
Запустил Hello World. Посчитал сколько в этом участвовало аббревиатур: .NET, CLI, CLR, MSVS, C#, GC. Нее... На C# писать нельзя.

Всё твоё возражение сводится к: "а оно выглядит страшно, я с этим никогда не работал, оно работать не будет". Как всегда.

Который раз ты уклоняешься от точного ответа, когда к стенке фактами припрут.

C>> По сути возражений нет — иди лесом.

НС>Это по сути. Лесники, кстати, очень часто в баньке бывают. Меня вот ни разу не банили, а тебя?
А мне пофиг. Полезного на RSDN всё равно ничерта нет.
Sapienti sat!
Re[7]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 14:40
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Ну так объясни что же это такое?

НС>Смысла не вижу тратить силы. Ты все равно никогда не слушаешь.
Слушаю. Ты, главное, факты приводи.
Sapienti sat!
Re[12]: WCF 4.0 vs Java what?
От: squid  
Дата: 06.06.10 16:19
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

C>Запустил Hello World. Посчитал сколько в этом участвовало аббревиатур: .NET, CLI, CLR, MSVS, C#, GC.


И все из них прекрасны!

C>Нее... На C# писать нельзя.


Ну и не пиши, а то напишешь фигню какую-нить и потом из-за нее .Net на форумах ругать будут!

C>Всё твоё возражение сводится к: "а оно выглядит страшно, я с этим никогда не работал, оно работать не будет". Как всегда.


Помнишь эксперимент в Alien 4 и фразу "Убееееей меня"? Вот это про то как в линуксе разработка делается! Зверюшку лучше пристрелить штоб не мучалась!

C>Который раз ты уклоняешься от точного ответа, когда к стенке фактами припрут.


Ну эт не ко мне

C>А мне пофиг. Полезного на RSDN всё равно ничерта нет.


Есть! ЕСТЬ!
Re[13]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 17:39
Оценка:
Здравствуйте, squid, Вы писали:

C>>Всё твоё возражение сводится к: "а оно выглядит страшно, я с этим никогда не работал, оно работать не будет". Как всегда.

S>Помнишь эксперимент в Alien 4 и фразу "Убееееей меня"? Вот это про то как в линуксе разработка делается! Зверюшку лучше пристрелить штоб не мучалась!
Странно, работаю в IntelliJ IDEA в Линуксе и всё ОК.
Sapienti sat!
Re[8]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.06.10 19:27
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


C>>>Ты мне задачу опиши, а я расскажу как на Java сделать.

G>>Вот отличный пример
G>>http://msdn.microsoft.com/en-us/magazine/ff646977.aspx
C>Только вот причём здесь WCF?..
Название: Visual Design of Workflows with WCF and WF 4

C>http://www.infoq.com/articles/jboss-esb-jbpm

C>http://www.jboss.org/jbossesb/screens.html

C>Абсолютно стандартный use-case для ESB-систем.


Именно.
А теперь пример с хостингом этого добра в своем приложении? Не скриншоты и overview, а хотябы tutorial.
Re[12]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.06.10 19:36
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


G>>>>Все виды security должны работать если поддерживаются каналом.

C>>>Как ты подпишешь сообщение JSON?
G>>Буду использовать HTTPS, если уже очень надо, то можно расширение протокола http забабахать, хотя смысла в этом не вижу.
G>>Так или иначе логика сервера и клиента не поменяется.
C>HTTPS — это канальный уровень, а не уровень сообщений. Вот XMLDSIG — это уровень сообщений, но не канальный.
И что? Тебе "шашечки" или "ехать" ?


G>>>>Мул кстати платный.

C>>>Кстати нет: http://www.mulesoft.org/mule-community-vs-mule-enterprise — у них определённая часть платная только.
G>>Community Edition — Evaluation or pre-production use...
G>>Для продакшена — платный.
C>Не, ну хватит бред нести.
Я только читаю то что на сайте.

C>Mule Community Edition доступен под http://en.wikipedia.org/wiki/Common_Public_Attribution_License , которая является weak copyleft-лицензией. Т.е. ты не обязан открывать исходный код своего приложения, но должен открыть исходный код Mule ESB и изменений в нём.

По лицензии Community Edition только для development и preproduction. Лицензия на исходный код не интересует.

C>>>Это просто для .NET нет нормального обобщённого API для мониторинга (WMI must die).

G>>WMI позволяет управлять и мониторить все, а JMX — то что на жабе написно, кагбе разная мощность технологий.
C>Не всё. Мой Линуксовый сервер через WMI не получится мониторить, так же как и сетевой принтер и роутер.
С чего ты взял? Современное железо вполне нормально WMI поддерживает. Никакой привязки к java, как в JMX, нету.

C>Для общего мониторинга есть SNMP, с которым JMX стыкуется без проблем. Только нафиг это надо?

Ну и WMI с SNMP подружить можно.

G>>>>А ссылки в нем — обычные URI

C>>>Добавь сюда гетерогенные сети и станет интересно
G>>А какая разница?
C>Файрволы и всё такое.
А причем тут файрволы и ссылки?

G>>>>Никак, просто контракт, не поддерживающий callback. Хотя никто не мешает тот же JSON гонять по net.tcp с callback.

C>>>Так вот в том-то и проблема.
G>>В чем? Пока клиенты json сервисов, а это на 99% javascript, не научится работать с callback, то смысла в таком решении нету.
G>>Надо реальные проблемы решать, а не абстрактные.
C>Так проблема реальная. Пришлось делать Comet-подобный транспортный протокол.
Тебе бы его все равно пришлось делать. Это ведь не проблема WCF, что rest+json не поддерживает callback.


C>WCF стыкуется с кучей всего, по заявлением MS. А на практике...

И на практике стыкуется.

C>>>И WCF предоставляет возможности роутинга сообщений и проксики. И там оно всё начинается...

G>>И что?
C>И то. Нету красоты.
Re[13]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 23:28
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Cyberax, Вы писали:


C>>Здравствуйте, gandjustas, Вы писали:


C>>HTTPS — это канальный уровень, а не уровень сообщений. Вот XMLDSIG — это уровень сообщений, но не канальный.

G>И что? Тебе "шашечки" или "ехать" ?
Хачу, чтоб всё работало. Везде.

C>>Mule Community Edition доступен под http://en.wikipedia.org/wiki/Common_Public_Attribution_License , которая является weak copyleft-лицензией. Т.е. ты не обязан открывать исходный код своего приложения, но должен открыть исходный код Mule ESB и изменений в нём.

G>По лицензии Community Edition только для development и preproduction. Лицензия на исходный код не интересует.
http://www.mulesoft.org/licensing-mule-esb — всё!

Там просто написано, что CE — это для pre-production'а. А для production'а лучше купить коммерческую поддержку. Но никаких запретов нет.

В любом случае, JBoss ESB — под LGPL, а Apache — под Apache 2.0

C>>Не всё. Мой Линуксовый сервер через WMI не получится мониторить, так же как и сетевой принтер и роутер.

G>С чего ты взял? Современное железо вполне нормально WMI поддерживает. Никакой привязки к java, как в JMX, нету.
WMI — это не кроссплатформенный стандарт. Нет его в Debian'е или Cisco. Там SNMP везде.

C>>Для общего мониторинга есть SNMP, с которым JMX стыкуется без проблем. Только нафиг это надо?

G>Ну и WMI с SNMP подружить можно.
Ну вот. А для .NET-приложений — WMI жутко неудобен по сравнению с JMX.

G>>>А какая разница?

C>>Файрволы и всё такое.
G>А причем тут файрволы и ссылки?
Не все ссылки доступны в обе стороны.

G>>>В чем? Пока клиенты json сервисов, а это на 99% javascript, не научится работать с callback, то смысла в таком решении нету.

G>>>Надо реальные проблемы решать, а не абстрактные.
C>>Так проблема реальная. Пришлось делать Comet-подобный транспортный протокол.
G>Тебе бы его все равно пришлось делать. Это ведь не проблема WCF, что rest+json не поддерживает callback.
Так нету магической прозрачности и независимости от архитектуры. О чём я сразу и сказал.

Напильником всё допиливается, но просто вопрос: "А причём здесь WCF?"
Sapienti sat!
Re[9]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 06.06.10 23:37
Оценка:
Здравствуйте, gandjustas, Вы писали:

C>>Только вот причём здесь WCF?..

G>Название: Visual Design of Workflows with WCF and WF 4
Так тема-то про WCF, а не WF.

C>>Абсолютно стандартный use-case для ESB-систем.

G>Именно.
G>А теперь пример с хостингом этого добра в своем приложении? Не скриншоты и overview, а хотябы tutorial.
Искать лень. http://dist.codehaus.org/mule/distributions/mule-2.2.1-embedded.jar — это вот официальная embedded-версия. К ней подключаешь JBPM и всё.

Или я делал через Maven:
            <dependency>
                <groupId>org.mule</groupId>
                <artifactId>mule-core</artifactId>
                <version>2.2.1</version>
            </dependency>
            <dependency>
                <groupId>org.drools</groupId>
                <artifactId>drools-core</artifactId>
                <version>5.0.1</version>
            </dependency>
            <dependency>
                <groupId>org.drools</groupId>
                <artifactId>drools-compiler</artifactId>
                <version>5.0.1</version>
            </dependency>

И оно всё скачается с зависимостями как надо. А дальше всё как обычно как в туториалах. Создаёшь конфигурацию через Spring, подклчюаешь нужные endpoint'ы и вперёд с песней.

Это же Java — всё просто и прозрачно. Просто берёшь кубики и собираешь что нужно, нет непрозрачных компонентов как в .NET
Sapienti sat!
Re[14]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.06.10 05:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


G>>Здравствуйте, Cyberax, Вы писали:


C>>>Здравствуйте, gandjustas, Вы писали:


C>>>HTTPS — это канальный уровень, а не уровень сообщений. Вот XMLDSIG — это уровень сообщений, но не канальный.

G>>И что? Тебе "шашечки" или "ехать" ?
C>Хачу, чтоб всё работало. Везде.
Что именно? Шифрование\подпись JSON в самом JSON без оберток? Так оно нигде работать не будет, и это не проблема WCF.


C>>>Не всё. Мой Линуксовый сервер через WMI не получится мониторить, так же как и сетевой принтер и роутер.

G>>С чего ты взял? Современное железо вполне нормально WMI поддерживает. Никакой привязки к java, как в JMX, нету.
C>WMI — это не кроссплатформенный стандарт. Нет его в Debian'е или Cisco. Там SNMP везде.
WMI вполне крослатформенный, не всеми поддерживается, как и JMX.

C>>>Для общего мониторинга есть SNMP, с которым JMX стыкуется без проблем. Только нафиг это надо?

G>>Ну и WMI с SNMP подружить можно.
C>Ну вот. А для .NET-приложений — WMI жутко неудобен по сравнению с JMX.
Это еще Linq не прикрутили к нему, на С9 уже показали прототип Linq2WMI. Остальные нервно курят в сторонке.

G>>>>А какая разница?

C>>>Файрволы и всё такое.
G>>А причем тут файрволы и ссылки?
C>Не все ссылки доступны в обе стороны.
Более того, ни одна ссылка не доступна в обе стороны.

G>>>>В чем? Пока клиенты json сервисов, а это на 99% javascript, не научится работать с callback, то смысла в таком решении нету.

G>>>>Надо реальные проблемы решать, а не абстрактные.
C>>>Так проблема реальная. Пришлось делать Comet-подобный транспортный протокол.
G>>Тебе бы его все равно пришлось делать. Это ведь не проблема WCF, что rest+json не поддерживает callback.
C>Так нету магической прозрачности и независимости от архитектуры. О чём я сразу и сказал.
Ты так и не понял что клиентский и серверный код не будут отличаться для разных каналов. А ты придумываешь какую-то неведомую ху**у
Пытаешься недостатки протоколов выставить недостатками WCF.

C>Напильником всё допиливается, но просто вопрос: "А причём здесь WCF?"

А WCF никуда не девается даже при использовании напильника.
Re[10]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.06.10 05:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


C>>>Только вот причём здесь WCF?..

G>>Название: Visual Design of Workflows with WCF and WF 4
C>Так тема-то про WCF, а не WF.

WCF — чисто передача данных, но основная сила не в самом WCF, а в его интеграции с WF.


C>Это же Java — всё просто и прозрачно. Просто берёшь кубики и собираешь что нужно, нет непрозрачных компонентов как в .NET


И прямо все кубики между собой совместимы? Что-то практика показывает обратное.
Надо немало опыта иметь чтобы нужные кубики собирать. В .NET такой проблемы нету, там единая платформа, которую можно расширять при желании.
Re[15]: WCF 4.0 vs Java what?
От: dotidot Россия  
Дата: 07.06.10 05:54
Оценка:
Здравствуйте, gandjustas, Вы писали:

C>>Ну вот. А для .NET-приложений — WMI жутко неудобен по сравнению с JMX.

G>Это еще Linq не прикрутили к нему, на С9 уже показали прототип Linq2WMI. Остальные нервно курят в сторонке.
зачем? этож вроде интерфейс для мониторинга, а не анализа собранных данных. для нормального анализа наверняка всё равно всё будет засунуто в РБД, ну а дальше как всегда.
Re[3]: WCF 4.0 vs Java what?
От: dotidot Россия  
Дата: 07.06.10 06:01
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Подобное поведение реализуется интеграцией WF4 и WCF.

я правильно понимаю, что wcf это реализация способа абстрагироваться от транспорта при условии rpc-style интерфейсов? оно простой message passing поддерживает?
Re[16]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.06.10 06:21
Оценка:
Здравствуйте, dotidot, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:


C>>>Ну вот. А для .NET-приложений — WMI жутко неудобен по сравнению с JMX.

G>>Это еще Linq не прикрутили к нему, на С9 уже показали прототип Linq2WMI. Остальные нервно курят в сторонке.
D>зачем? этож вроде интерфейс для мониторинга, а не анализа собранных данных. для нормального анализа наверняка всё равно всё будет засунуто в РБД, ну а дальше как всегда.

Для красивого мониторинга, сейчас модель программирования WMI очень тяжелая, текстовые запросы, слаботипизированные ответы. Linq, как и в случае с БД, позволяет все это добро сделать типизированным и проверяемым при компиляции.
Re[4]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.06.10 06:23
Оценка:
Здравствуйте, dotidot, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:


G>>Подобное поведение реализуется интеграцией WF4 и WCF.

D>я правильно понимаю, что wcf это реализация способа абстрагироваться от транспорта при условии rpc-style интерфейсов? оно простой message passing поддерживает?

А что значит "простой message passing" ?
Re: WCF 4.0 vs Java what?
От: Mamut Швеция http://dmitriid.com
Дата: 07.06.10 07:27
Оценка:
VV>Вот в лагере додНЕда есть прекрасная штука — WCF, от которой волосы становятся мягкими и шолковистыми даже на спине. Сейчас вышла 4 версия, которая фигурально выражаясь позволяет вообще все, что нужно сделать через себя и очень просто, а вот есть ли в стане Java что-нибудь настолько же хорошее?

Настолько прекрасная, что никто ее в глаза не видел?


dmitriid.comGitHubLinkedIn
Re[5]: WCF 4.0 vs Java what?
От: dotidot Россия  
Дата: 07.06.10 07:33
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А что значит "простой message passing" ?

ну я умными словами не горазд, поэтому попробую веслом:
— можно дернуть метод int f(int), интерфейса I, и синхронно/асинхронно ждать ответа. для связи в обратную сторону применять polling или callback (как ни странно часто оказывается неимоверно тяжелой штукой, особенно для простых аргументов, например, в omniorb). это rpc style
— а можно просто послать сообщение messageType1{int}, и соотв. просто получить сообщение messageType2{int} без вызова методов. некоторые этот способ erlang style называют. для эмуляции вызова методов (или состояния) добавляют к сообщениям correlation id. очень удобный способ для потоковой передачи сообщений в обе стороны, когда сообщения друг от друга не зависят, асинхронных уведомлений, для тех же системных датчиков.
Re[6]: WCF 4.0 vs Java what?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.06.10 08:02
Оценка:
Здравствуйте, dotidot, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:


G>>А что значит "простой message passing" ?

D>ну я умными словами не горазд, поэтому попробую веслом:
D>- можно дернуть метод int f(int), интерфейса I, и синхронно/асинхронно ждать ответа. для связи в обратную сторону применять polling или callback (как ни странно часто оказывается неимоверно тяжелой штукой, особенно для простых аргументов, например, в omniorb). это rpc style
D>- а можно просто послать сообщение messageType1{int}, и соотв. просто получить сообщение messageType2{int} без вызова методов. некоторые этот способ erlang style называют. для эмуляции вызова методов (или состояния) добавляют к сообщениям correlation id. очень удобный способ для потоковой передачи сообщений в обе стороны, когда сообщения друг от друга не зависят, асинхронных уведомлений, для тех же системных датчиков.

Я понял.
Это два подхода, называемые Message Bus и RPC. Они полностью изоморфны друг другу.

Из RPC получить Message Bus (также именуемый Publish\Subscribe) очень просто: Делается сервис Bus, на этом Bus получатели регистрируют свои endpoint_ы, и фильтры тех сообщений, которые они хотят получать, клиенты Bus могу отправить ему сообщения, а сам Bus найдет кому его передать.

Из Message Bus сделать сделать RPC тоже довольно просто — к каждому Message добавить идентификатор получателя и sequence id чтобы отслеживать последовательность запросов — ответов.

В случае message bus нужен явный диспетчер — этот самый bus, в erlang он встроен в VM.

WCF нативно дает интерфейсы RPC-style.
В динамически типизированных языках различия интерфейсов стираются. Вызов RPC метода можно представить как отправку сообщения с именем метода и параметрами.
Re: WCF 4.0 vs Java what?
От: GarryIV  
Дата: 07.06.10 09:32
Оценка:
Здравствуйте, vladimir.vladimirovich, Вы писали:

VV>Вот в лагере додНЕда есть прекрасная штука — WCF, от которой волосы становятся мягкими и шолковистыми даже на спине. Сейчас вышла 4 версия, которая фигурально выражаясь позволяет вообще все, что нужно сделать через себя и очень просто, а вот есть ли в стане Java что-нибудь настолько же хорошее?


Очередная аббривеатура от MS которая "фигурально выражаясь позволяет вообще все"?
Наивно полагать, что в Java недостаток аббривеатур Я бы скорее сказал, что некоторый избыток

Скорее всего нет маппинга 1 в 1 на аббриветуру из Java.
WBR, Igor Evgrafov
Re[11]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 07.06.10 10:45
Оценка:
Здравствуйте, gandjustas, Вы писали:

C>>Так тема-то про WCF, а не WF.

G>WCF — чисто передача данных, но основная сила не в самом WCF, а в его интеграции с WF.
Скорее интеграции WF с WCF...

C>>Это же Java — всё просто и прозрачно. Просто берёшь кубики и собираешь что нужно, нет непрозрачных компонентов как в .NET

G>И прямо все кубики между собой совместимы? Что-то практика показывает обратное.
Вот как ни странно — да, совместимы. А в Spring со всем есть интеграция. Уж каких только монстриков я не творил в нём

G>Надо немало опыта иметь чтобы нужные кубики собирать. В .NET такой проблемы нету, там единая платформа, которую можно расширять при желании.

Опыт нужен, конечно. Но как-то мне нафиг не надо, чтобы архитектуру большого enterprise-приложения писали индусы с годом опыта.
Sapienti sat!
Re[17]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 07.06.10 11:47
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Для красивого мониторинга, сейчас модель программирования WMI очень тяжелая, текстовые запросы, слаботипизированные ответы. Linq, как и в случае с БД, позволяет все это добро сделать типизированным и проверяемым при компиляции.

Зачем? Один фиг все нормальные люди складывают данные в системы мониторинга (HP OpenView, Nagios, zenoss, OpenNMS и другие). А дальше там уже можно хоть через web-сервисы общаться.
Sapienti sat!
Re[18]: WCF 4.0 vs Java what?
От: Klikujiskaaan КНДР  
Дата: 07.06.10 13:50
Оценка:

Нормальные люди пишут сразу в машинных кодах и напрямую работают с tcp\ip стеком.
Re[19]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 07.06.10 15:12
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

K>Нормальные люди пишут сразу в машинных кодах и напрямую работают с tcp\ip стеком.

Ну вот не знаешь, а говоришь.
Sapienti sat!
Re[7]: WCF 4.0 vs Java what?
От: Cyberax Марс  
Дата: 07.06.10 15:27
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Из Message Bus сделать сделать RPC тоже довольно просто — к каждому Message добавить идентификатор получателя и sequence id чтобы отслеживать последовательность запросов — ответов.

И эти люди ещё жалуются, что в Java всё низкоуровневое. Прямо на уровне TCP/IP надо работать...
Sapienti sat!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.