Платформа для создания распределённых сервисов (то есть это RCP, а не REST) прозрачно по отношению с протоколу передачи данных (RAW TCP, Named pipe, HTTP), с наворотками (шифрование, сессии). Хотя и по стилю RPC, в отличие от Remoting не поддерживает MarshalByRef.
Здравствуйте, Lloyd, Вы писали:
L>Отвечает на твои вопросы. Если есть более частные вопросы, задавай.
Я просто пытаюсь понять общую идею.
Это абстракция над разными протоколами передачи, ок, с этим ясно. stateful, если я правильно понял. Что там еще важного, какие основные "киты" на которых это всё стоит?
Здравствуйте, Klatu, Вы писали:
K>Что там еще важного, какие основные "киты" на которых это всё стоит?
Можно один и тот же сервис публиковать по разным протоколам одновременно, менять это из конфигурационного файла.
Можно даже HTTP-сервис хостить в своём приложении и это будет не менее эффективно, чем в IIS.
Много чего можно. Может расскажешь для чего тебе нужно, а тебе ответят подходит ли WCF?
Здравствуйте, Klatu, Вы писали:
L>>Отвечает на твои вопросы. Если есть более частные вопросы, задавай.
K>Я просто пытаюсь понять общую идею. K>Это абстракция над разными протоколами передачи, ок, с этим ясно.
K>stateful, если я правильно понял.
stateless, но сессии можно использовать
K>Что там еще важного, какие основные "киты" на которых это всё стоит?
SOA, отделение контракта, секьюрити, транзакции из каробки, разные транспорты и способы сериализации сообщений, расширяемость.
K>кто-нибудь может объяснить без хайпа, что оно делает и зачем нужно?
Огромный коммуникационный фреймворк:
1) большое количество сценариев взаимодействия решается соответствующей настройкой конфигурации (протоколы, форматы, шифрование, безопасность etc)
2) много точек расширения для реализации собственной логики
3) в качестве хоста может выступать практически что угодно (даже консольное приложение)
Здравствуйте, Klatu, Вы писали:
K>кто-нибудь может объяснить без хайпа, что оно делает и зачем нужно?
Если использовал .Net Remoting то на пальцах (обобщенно) это тоже самое только более абстрагированное, в силу чего становится более мультиплатформенным.
-----------------------------------------
тут может быть ваша реклама
Здравствуйте, Klatu, Вы писали:
A>>Много чего можно. Может расскажешь для чего тебе нужно, а тебе ответят подходит ли WCF?
K>Да я просто интересуюсь, чтобы быть в курсе. K>В чем основные отличия от Remoting, если не считать абстракцию над протоколами?
Если в двух словах, то WCF — это очередная библиотека для межпроцессного взаимодействия, которая является логическим развитием предыдущих подобных технологий мелкомягковский, в частности .Net Remoting и DCOM. Существенным отличием от двух предыдущих технологий является то, что WCF — это прежде всего технология для построения сервис-ориентированной архитектуры приложений (SOA — Service-Oriented Architecture), что позволяет абстрагироваться от конкретной технологии реализации и взаимодействовать с другими приложениями, написанными на любой другой платформе, языке, технологии (главное, чтобы эта реализация отвечала определенным правилам).
Если вы знакомы с ремоутингом, то отличия основные следующие: по-умолчанию, WCF не показывает наружу (not expose) никакие платформенно-зависимые детали реализации сервиса, такие как типы аргументов методов сервиса. Вместо этого, сервис представляет собой группу операций, которые получают некоторые абстрактные входные/выходные параметры. В частности, это позволяет написать сервис на WCF, а использовать его из Java. При этом существует такое понятие, как эквивалентность типов параметров, когда два типа считаются эквивалентными, если они имеют одно и тоже представление на уровне канала передачи данных, то их можно спокойно использовать взаимозаменяемым образом. Таким образом, можно ослабить зависимость между клиентом и сервисом и полностью устранить зависимость на уровне сборок: сервис публикует информацию о себе с помощью специального mex-интерфейса (так называемый Metadata Exchange Endpoint), и любой другой клиент (написанный на .net или любой другой технологии) может к нему подключиться и сгенерировать прокси-классы для взаимодействия с этим сервисом. Таким образом получается, что два типа являются эквивалентными, если они имеют одно и тоже представление на уровне канала передачи данных, что позволяет их посылать со стороны клиента и получать на стороне сервиса (и наоборот).
Кроме того, в DCOM и в ремоутинге было такое понятие, как прозрачность метоположение (location transparancy), т.е. мы на самом деле не знаем, является ли полученный нами объект реальным объектом, или же он является проксей к удаленному объекту (на самом деле узнать это можно вызвав RemotingServices.IsTransparentProxy но дело не в этом). В девяностых (и начале двухтысячных), многим казалось хорошей идеей, что мы можем работать с некоторым объектом и не задумываться над тем, является ли он локальным или удаленным, но практика показала, что пользовательский код должен четко знать, что он работает с удаленным объектом, поскольку это упрощает разделение коммуникационных ошибок от ошибок бизнес-логики, генерируемых удаленным объектом. Так что в WCF теперь есть четкое разделение и понимание того, что вы работаете с прокси, и вы можете спокойно отделить коммуникационные ошибки (Communication exceptions), от ошибок, произошедших в сервисе/клиенте. Все некоммуникационные ошибки также являются частью протокола взаимодействия между клиентом и сервисом (ведь мы можем работать с платформой у которых исключений может не быть вообще), поэтому они четко специфицируются в виде Faul Contract-ов, так что теперь, каждый метод сервиса должен четко говорить, что он может упасть и с чем.
Если вдаваться еще в какие-то частности различий в WCF и .Net Remoting, то процесс обратных вызовов (callbacks) в них реализован соверешнно по разному. Так, в WCF интерфейс обратного вызова также является частью контракта и задается непосредственно в контракте сервиса, это дает возможность в каждом вызове сервиса получить этот интерфейс, в случае необходимости сохранить его и потом вызвать метод этого интерфейса. Это поддерживается не всеми коммуникационными протоколами (посколько некоторые протоколы являются по своей сути однонаправленными) и тогда, в случае несовместимости, вы получите ошибку в процессе создания экземпляра сервиса.
Кроме этого, есть и очень важные отличия при использовании протокола Tcp, при работе с двусторонними каналами связи. Вообще, в ремоутинге с надежной двусторонней связью была полная беда, даже в букварях было написано, что реализовать надежную связь на ремоутинге через TCP было практически невозможно: ремоутинг втихую пытается восстановить соединение от клиента к серверу, а связь от сервера к клиенту автоматом не восстанавливалась (поскольку восстанавление происходило втихаря в момент вызова метода) и, самое главное, для обратной связи в ремоутинге требуется еще одно tcp-шное соединение, что делает невозможным нахождение клиента за NAT-ом.
adontz упоминал, что в WCF мы не можем воспользоваться MarshalByRef; формально — это действительно так, но на практике вы можете достаточно легко перейти с ремоутинга (использования MarshalByRef), на WCF сменив в WCF сериализатор по умолчанию с NetDataContractSerializer-а на NetDataContractSerializer-ом. Этот сериализатор, в отличие от сериализатора по умолчанию, добавляет в выходной сериализованный поток информацию о CLR-ном типе, что устраняет сервис-ориентированную кросс-платформенность, но позволяет использовать любые сериализируемые классы в виде аргументов (если классы аргументов использовались в ремоутинге и были помечены атрибутом Serializable, то их можно будет использовать и в WCF при использовании в нем NetDataContractSerializer-а).
В остальном, WCF является таким же "слоеным пирогом", как и ремоутинг, только количество этих слоев и их названия немного другие. Так что, если вам не хватает функциональности из коробки, то это дело можно расширить.
Если очень коротко, то вся инфраструктура состоит из двух главных слоев: 1. Service Model Layer и 2. Channel Layer. Каждый из этих слоев содержит еще кучу подуровней и вы можете вклиниться в каждый из них. Так, например, можно валидировать параметры обобщенным образом (например, всегда нужно, чтобы объекты определенного типа, которые используются в десятке методов сервиса обладали определенной характеристикой), самому создавать WCF сообщения, изменять существующие (добавив кастомное шифрование или что угодное еще), добавлять свои собственные каналы, которые, например, будут работать по UDP с вашей собственной кастомной системой по вашему собственному кастомному коммуникационному протоколу.
Так же, есть поддержка безопасности, транзакций; существует разные варианты инстанцирования экземпляров сервиса: на каждый вызов; на сессию; синглтон. Есть разные настройки по надежности доставки сообщений; можно настраивать таймауты, максимальные размеры сообщений и многое другое. Все это делается либо из кода, либо из конфигурационного файла.
В общем выводы такие:
Если на платформе .net вам понадобится межпроцессное взаимодействие, то первое на что стоит посмотреть — это WCF. Скорее всего, даже функциональности из коробки вам будет достаточно для реализации всех ваших потребностей, если же этого будет недостаточно, то вы всегда сможете расширить эту функциональность, по мере необходимости.
Здравствуйте, Klatu, Вы писали:
K>Здравствуйте, SergeyT., Вы писали:
ST>>сменив в WCF сериализатор по умолчанию с NetDataContractSerializer-а на NetDataContractSerializer-ом.
K>
Здравствуйте, Klatu, Вы писали:
K>кто-нибудь может объяснить без хайпа, что оно делает и зачем нужно?
Довольно лаконично:
Windows Communication Foundation (WCF) provides a programming framework that
abstracts out the complexities of creating services. It does this for nearly every element of
the service and bindings is probably one of the most important areas. This allows you as the
programmer to concentrate on the problem at hand, and not worry about how to create
architecture that allows your system to work. The foundation is there already.
To define a service endpoint (as described in previous chapters), you must implement the ABCs
of WCF. This stands for Address, Binding, and Contract — or the Where, How, and What of
a service.
The Address is where the service is hosted, either for the service as a reference, or so
the client knows where to send the message.
The Binding is the how of the services, and defi nes how the messages are sent and
received.
The Contract is the defi nition of what the message contains...
PS. Один и тот-же сервис может иметь множество endpoint, которые описываются как ABC(см. выше)
