Здравствуйте, gandjustas, Вы писали:
C>>Это умеет любой business process execution движок... G>а)их не так много
А зачем много-то?
G>б)WF + WCF можно масштабировать в любую сторону
И не он один.
C>>И WCF тут играет роль банального локатора + RPC. G>WCF это вообще абстракция над каналами связи. Предоставляет единую модель программирования и конфигурации для любых средств связи между приложениями.
Ой, ну не надо сказок рассказывать только. "Сетевая прозрачность", "независимость от транспорта" — это уже всё было в начале 90-х. На практике, оно всё один фиг непрозрачное и зависимое.
Модель программирования для REST-ful web-сервисов и CORBA-style RPC будет отличаться просто из-за своих фундаментальных основ.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Аналоги WCF — это Spring + система экспортёров + JMS НС>Сильно, ничего не скажешь.
Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения.
Здравствуйте, 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 предоставляет возможности роутинга сообщений и проксики. И там оно всё начинается...
И что?
Здравствуйте, Cyberax, Вы писали:
C>Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения.
В очередной раз убеждаюсь, что ты плохо представляешь себе предмет спора. Надергал какие то обрывки из статей, а остальное додумал. Нет, WCF это не Spring+JMS даже близко.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>А теперь посчитай количество абрривеатур и технологий, которые ты в своем сообщении помянул. C>>И что? НС>Поясню. Любая практически задача может быть решена пачкой библиотек и рукопашным кодированием. Вопрос в том, насколько качественно и какой ценой. Чем больше разноплановых библиотек (особенно таких монстров как Spring) вовлечено в решение задачи, тем означенная цель менее достижима. Все просто.
Запустил Hello World. Посчитал сколько в этом участвовало аббревиатур: .NET, CLI, CLR, MSVS, C#, GC. Нее... На C# писать нельзя.
Всё твоё возражение сводится к: "а оно выглядит страшно, я с этим никогда не работал, оно работать не будет". Как всегда.
Который раз ты уклоняешься от точного ответа, когда к стенке фактами припрут.
C>> По сути возражений нет — иди лесом. НС>Это по сути. Лесники, кстати, очень часто в баньке бывают. Меня вот ни разу не банили, а тебя?
А мне пофиг. Полезного на RSDN всё равно ничерта нет.
Здравствуйте, Cyberax, Вы писали:
C>Запустил Hello World. Посчитал сколько в этом участвовало аббревиатур: .NET, CLI, CLR, MSVS, C#, GC.
И все из них прекрасны!
C>Нее... На C# писать нельзя.
Ну и не пиши, а то напишешь фигню какую-нить и потом из-за нее .Net на форумах ругать будут!
C>Всё твоё возражение сводится к: "а оно выглядит страшно, я с этим никогда не работал, оно работать не будет". Как всегда.
Помнишь эксперимент в Alien 4 и фразу "Убееееей меня"? Вот это про то как в линуксе разработка делается! Зверюшку лучше пристрелить штоб не мучалась!
C>Который раз ты уклоняешься от точного ответа, когда к стенке фактами припрут.
Ну эт не ко мне
C>А мне пофиг. Полезного на RSDN всё равно ничерта нет.
Вот в лагере додНЕда есть прекрасная штука — WCF, от которой волосы становятся мягкими и шолковистыми даже на спине. Сейчас вышла 4 версия, которая фигурально выражаясь позволяет вообще все, что нужно сделать через себя и очень просто, а вот есть ли в стане Java что-нибудь настолько же хорошее?
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Вот в лагере додНЕда есть прекрасная штука — WCF, от которой волосы становятся мягкими и шолковистыми даже на спине. Сейчас вышла 4 версия, которая фигурально выражаясь позволяет вообще все, что нужно сделать через себя и очень просто, а вот есть ли в стане Java что-нибудь настолько же хорошее?
Я долго на него смотрел и не мог понять: а нафиг он нужен-то?
Аналоги WCF — это Spring + система экспортёров + JMS. Каждая часть там занимается своей работой.
WF описывает высокоуровневый сценарий, который может полностью выгружаться, например при длительных операциях, и "просыпаться" на другой машине при необходимости. В сценарий WF можно воткнуть WCF действия типа "прием запроса от endpoint-а" и "отдача ответа в endpoint".
А также в RC находится Window Server Appfabric, которая изкаропки дает готовую среду для хостинга таких процессов на IIS (она и так доступна, но настраивать надо), средства мониторинга и трассировки.
А также в разработке DSL на базе M (Oslo), который позволит эти самые процессы описывать в виде текста.
Здравствуйте, vladimir.vladimirovich, Вы писали:
C>>Аналоги WCF — это Spring + система экспортёров + JMS. Каждая часть там занимается своей работой. VV>Spring и JMS — это про то, как доставить что-то куда-то, А wcf — это еще и что сделать с этим чем-то. Уровень абстракции выше.
Это не уровень абстракции, а неправильный дизайн...
Здравствуйте, gandjustas, Вы писали:
G>WF описывает высокоуровневый сценарий, который может полностью выгружаться, например при длительных операциях, и "просыпаться" на другой машине при необходимости. В сценарий WF можно воткнуть WCF действия типа "прием запроса от endpoint-а" и "отдача ответа в endpoint".
Это умеет любой business process execution движок... И WCF тут играет роль банального локатора + RPC.
Более интересен пример оркестрации с распределёнными транзакциями и контекстом безопасности. Точнее то, насколько всё оно угрёбищно сделано ВЕЗДЕ.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>WF описывает высокоуровневый сценарий, который может полностью выгружаться, например при длительных операциях, и "просыпаться" на другой машине при необходимости. В сценарий WF можно воткнуть WCF действия типа "прием запроса от endpoint-а" и "отдача ответа в endpoint". C>Это умеет любой business process execution движок...
а)их не так много
б)WF + WCF можно масштабировать в любую сторону
C>И WCF тут играет роль банального локатора + RPC.
WCF это вообще абстракция над каналами связи. Предоставляет единую модель программирования и конфигурации для любых средств связи между приложениями.
C>Более интересен пример оркестрации с распределёнными транзакциями и контекстом безопасности. Точнее то, насколько всё оно угрёбищно сделано ВЕЗДЕ.
С безопасностью еще нормально, а с транзакциями вообще везде угребищно. ИМХО распределенные транзакции — вообще плохая идея.
Здравствуйте, Cyberax, Вы писали:
C>Это умеет любой business process execution движок... И WCF тут играет роль банального локатора + RPC.
И очень надеюсь, что никакой другой роли он никогда играть не будет. WCF это только и исключительно коммуникационный слой, а не все мухи в котлетах ака CORBA.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Это умеет любой business process execution движок... И WCF тут играет роль банального локатора + RPC. НС>И очень надеюсь, что никакой другой роли он никогда играть не будет. WCF это только и исключительно коммуникационный слой, а не все мухи в котлетах ака CORBA.
Поздно. В WCF уже входят распределённые транзакции и прочая гадость.
Здравствуйте, henson, Вы писали:
RO>>>А как в WCF задавать асинхронные операции, коллбеками или yield return? VV>>А вы с какой целью интересуетесь? H>Очевидно это провокация :))
А с какой целью можно задавать такие вопросы в этом форуме? Можно будет поругать WCF за синтаксический оверхед.
Здравствуйте, 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-* вебсервис.
Так что никакие "фундаментальные основы" не мешают использовать абсолютно одинаковую модель как на сервере, так и на клиенте.
Здравствуйте, 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, там типы "последовательность" и "последовательность_из_строго_пяти_элементов" — это разные вещи. И если у тебя тип потеряется во время передачи (а он один фиг потеряется, у других форматов нет такого кретинизма) — результат не будет валидным для нужной схемы.
Это не то, это продукты 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 — тоже отлично работает.
Здравствуйте, Cyberax, Вы писали:
C>Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения.
С помощью TCP вообще можно то же самое сделать. ага...
Здравствуйте, 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 некрасивого? Это просто стандарт на обобщённую систему управления и мониторинга.
Это просто для .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 предоставляет возможности роутинга сообщений и проксики. И там оно всё начинается...
Здравствуйте, vladimir.vladimirovich, Вы писали:
C>>Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения. VV>С помощью TCP вообще можно то же самое сделать. ага...
Ты мне задачу опиши, а я расскажу как на Java сделать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vladimir.vladimirovich, Вы писали:
C>>>Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения. VV>>С помощью TCP вообще можно то же самое сделать. ага... C>Ты мне задачу опиши, а я расскажу как на Java сделать.
Я чего-то не пойму, или это десятка полтора строк, заодно в полностью асинхронном варианте?
@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 — конечно, хорошо, но три поставщика отдельными блоками вместо цикла наводят на мысль о том, что оно просто не умеет оформлять циклы. О замене программирования перетаскиванием блоков туда-сюда говорят уже давно, но ничего дельного пока не замечено.
Здравствуйте, 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 тоже такое есть, но по наглядности блоки со стрелочками покачто рулят.
Здравствуйте, 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>И что?
И то. Нету красоты.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения. НС>В очередной раз убеждаюсь, что ты плохо представляешь себе предмет спора. Надергал какие то обрывки из статей, а остальное додумал. Нет, WCF это не Spring+JMS даже близко.
Ну так объясни что же это такое?
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>...и это только мои личные примеры... НС>А теперь посчитай количество абрривеатур и технологий, которые ты в своем сообщении помянул.
И что? По сути возражений нет — иди лесом.
Здравствуйте, Cyberax, Вы писали:
НС>>А теперь посчитай количество абрривеатур и технологий, которые ты в своем сообщении помянул. C>И что?
Поясню. Любая практически задача может быть решена пачкой библиотек и рукопашным кодированием. Вопрос в том, насколько качественно и какой ценой. Чем больше разноплановых библиотек (особенно таких монстров как Spring) вовлечено в решение задачи, тем означенная цель менее достижима. Все просто.
C> По сути возражений нет — иди лесом.
Это по сути. Лесники, кстати, очень часто в баньке бывают. Меня вот ни разу не банили, а тебя?
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Ну так объясни что же это такое? НС>Смысла не вижу тратить силы. Ты все равно никогда не слушаешь.
Слушаю. Ты, главное, факты приводи.
Здравствуйте, squid, Вы писали:
C>>Всё твоё возражение сводится к: "а оно выглядит страшно, я с этим никогда не работал, оно работать не будет". Как всегда. S>Помнишь эксперимент в Alien 4 и фразу "Убееееей меня"? Вот это про то как в линуксе разработка делается! Зверюшку лучше пристрелить штоб не мучалась!
Странно, работаю в IntelliJ IDEA в Линуксе и всё ОК.
Здравствуйте, 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>И то. Нету красоты.
Здравствуйте, 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?"
Здравствуйте, 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 и всё.
И оно всё скачается с зависимостями как надо. А дальше всё как обычно как в туториалах. Создаёшь конфигурацию через Spring, подклчюаешь нужные endpoint'ы и вперёд с песней.
Это же Java — всё просто и прозрачно. Просто берёшь кубики и собираешь что нужно, нет непрозрачных компонентов как в .NET
Здравствуйте, 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 никуда не девается даже при использовании напильника.
Здравствуйте, 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 такой проблемы нету, там единая платформа, которую можно расширять при желании.
Здравствуйте, gandjustas, Вы писали:
C>>Ну вот. А для .NET-приложений — WMI жутко неудобен по сравнению с JMX. G>Это еще Linq не прикрутили к нему, на С9 уже показали прототип Linq2WMI. Остальные нервно курят в сторонке.
зачем? этож вроде интерфейс для мониторинга, а не анализа собранных данных. для нормального анализа наверняка всё равно всё будет засунуто в РБД, ну а дальше как всегда.
Здравствуйте, gandjustas, Вы писали:
G>Подобное поведение реализуется интеграцией WF4 и WCF.
я правильно понимаю, что wcf это реализация способа абстрагироваться от транспорта при условии rpc-style интерфейсов? оно простой message passing поддерживает?
Здравствуйте, dotidot, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
C>>>Ну вот. А для .NET-приложений — WMI жутко неудобен по сравнению с JMX. G>>Это еще Linq не прикрутили к нему, на С9 уже показали прототип Linq2WMI. Остальные нервно курят в сторонке. D>зачем? этож вроде интерфейс для мониторинга, а не анализа собранных данных. для нормального анализа наверняка всё равно всё будет засунуто в РБД, ну а дальше как всегда.
Для красивого мониторинга, сейчас модель программирования WMI очень тяжелая, текстовые запросы, слаботипизированные ответы. Linq, как и в случае с БД, позволяет все это добро сделать типизированным и проверяемым при компиляции.
Здравствуйте, dotidot, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
G>>Подобное поведение реализуется интеграцией WF4 и WCF. D>я правильно понимаю, что wcf это реализация способа абстрагироваться от транспорта при условии rpc-style интерфейсов? оно простой message passing поддерживает?
VV>Вот в лагере додНЕда есть прекрасная штука — WCF, от которой волосы становятся мягкими и шолковистыми даже на спине. Сейчас вышла 4 версия, которая фигурально выражаясь позволяет вообще все, что нужно сделать через себя и очень просто, а вот есть ли в стане Java что-нибудь настолько же хорошее?
Настолько прекрасная, что никто ее в глаза не видел?
Здравствуйте, gandjustas, Вы писали:
G>А что значит "простой message passing" ?
ну я умными словами не горазд, поэтому попробую веслом:
— можно дернуть метод int f(int), интерфейса I, и синхронно/асинхронно ждать ответа. для связи в обратную сторону применять polling или callback (как ни странно часто оказывается неимоверно тяжелой штукой, особенно для простых аргументов, например, в omniorb). это rpc style
— а можно просто послать сообщение messageType1{int}, и соотв. просто получить сообщение messageType2{int} без вызова методов. некоторые этот способ erlang style называют. для эмуляции вызова методов (или состояния) добавляют к сообщениям correlation id. очень удобный способ для потоковой передачи сообщений в обе стороны, когда сообщения друг от друга не зависят, асинхронных уведомлений, для тех же системных датчиков.
Здравствуйте, 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 метода можно представить как отправку сообщения с именем метода и параметрами.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Вот в лагере додНЕда есть прекрасная штука — WCF, от которой волосы становятся мягкими и шолковистыми даже на спине. Сейчас вышла 4 версия, которая фигурально выражаясь позволяет вообще все, что нужно сделать через себя и очень просто, а вот есть ли в стане Java что-нибудь настолько же хорошее?
Очередная аббривеатура от MS которая "фигурально выражаясь позволяет вообще все"?
Наивно полагать, что в Java недостаток аббривеатур Я бы скорее сказал, что некоторый избыток
Скорее всего нет маппинга 1 в 1 на аббриветуру из Java.
Здравствуйте, gandjustas, Вы писали:
C>>Так тема-то про WCF, а не WF. G>WCF — чисто передача данных, но основная сила не в самом WCF, а в его интеграции с WF.
Скорее интеграции WF с WCF...
C>>Это же Java — всё просто и прозрачно. Просто берёшь кубики и собираешь что нужно, нет непрозрачных компонентов как в .NET G>И прямо все кубики между собой совместимы? Что-то практика показывает обратное.
Вот как ни странно — да, совместимы. А в Spring со всем есть интеграция. Уж каких только монстриков я не творил в нём
G>Надо немало опыта иметь чтобы нужные кубики собирать. В .NET такой проблемы нету, там единая платформа, которую можно расширять при желании.
Опыт нужен, конечно. Но как-то мне нафиг не надо, чтобы архитектуру большого enterprise-приложения писали индусы с годом опыта.
Здравствуйте, gandjustas, Вы писали:
G>Для красивого мониторинга, сейчас модель программирования WMI очень тяжелая, текстовые запросы, слаботипизированные ответы. Linq, как и в случае с БД, позволяет все это добро сделать типизированным и проверяемым при компиляции.
Зачем? Один фиг все нормальные люди складывают данные в системы мониторинга (HP OpenView, Nagios, zenoss, OpenNMS и другие). А дальше там уже можно хоть через web-сервисы общаться.
Здравствуйте, Klikujiskaaan, Вы писали:
K>Нормальные люди пишут сразу в машинных кодах и напрямую работают с tcp\ip стеком.
Ну вот не знаешь, а говоришь.
Здравствуйте, gandjustas, Вы писали:
G>Из Message Bus сделать сделать RPC тоже довольно просто — к каждому Message добавить идентификатор получателя и sequence id чтобы отслеживать последовательность запросов — ответов.
И эти люди ещё жалуются, что в Java всё низкоуровневое. Прямо на уровне TCP/IP надо работать...
