Вот в лагере додНЕда есть прекрасная штука — 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 уже входят распределённые транзакции и прочая гадость.
Здравствуйте, gandjustas, Вы писали:
C>>Это умеет любой business process execution движок... G>а)их не так много
А зачем много-то?
G>б)WF + WCF можно масштабировать в любую сторону
И не он один.
C>>И WCF тут играет роль банального локатора + RPC. G>WCF это вообще абстракция над каналами связи. Предоставляет единую модель программирования и конфигурации для любых средств связи между приложениями.
Ой, ну не надо сказок рассказывать только. "Сетевая прозрачность", "независимость от транспорта" — это уже всё было в начале 90-х. На практике, оно всё один фиг непрозрачное и зависимое.
Модель программирования для REST-ful web-сервисов и CORBA-style RPC будет отличаться просто из-за своих фундаментальных основ.
Здравствуйте, 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-* вебсервис.
Так что никакие "фундаментальные основы" не мешают использовать абсолютно одинаковую модель как на сервере, так и на клиенте.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Аналоги WCF — это Spring + система экспортёров + JMS НС>Сильно, ничего не скажешь.
Ну таки да. Что именно умеет WCF — я тебе (почти) всё сделаю с помощью этой комбинации. Ты учти, что туда можно ещё всякий Mule воткнуть и прочие извращения.
Здравствуйте, 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 — тоже отлично работает.
