2012-06-01 6 views
3

Например, может ли служба WCF выступать в качестве фабрики для других служб WCF? .: напримерМожет ли одна служба WCF вернуть другую?

[ServiceContract(Namespace = "Foo")] 
interface IThing 
{ 
    [OperationContract] 
    void DoSomething(); 
} 

[ServiceContract(Namespace = "Foo")] 
interface IMakeThings 
{ 
    [OperationContract] 
    IThing Create(string initializationData); 
} 

Аналогично может принять интерфейс другой интерфейс в качестве параметра?

[ServiceContract(Namespace = "Foo")] 
interface IUseThings 
{ 
    [OperationContract] 
    void UseThing(IThing target); 
} 

Будет ли это требовать регулировки известных типов?

Все интерфейсы будут определены спереди и известны как клиенту, так и службе.

+0

Нет. WCF - это ** система на основе сообщений - она ​​передает XML-сериализацию ** данные ** (и только данные - без кода или методов) от клиента к серверу и обратно. Это ** НЕ *, предназначенное для того, чтобы быть чем-то вроде удаленного доступа или поддержки «вызова удаленного объекта» или что-то в этом роде. –

+0

На стороне клиента есть прокси, а не реальные экземпляры службы. Поэтому вопрос не имеет смысла. –

+1

Возможно, мне что-то не хватает, но теоретически было бы возможно, чтобы клиентская сторона обернула результат возврата IMakeThings.Create() в соответствующий прокси-сервер «IThing» на основе привязок к службе «IMakeThings». Ответ на этот вопрос вполне может быть «нет», что хорошо, но я думаю, что сам вопрос имеет смысл. – WaffleSouffle

ответ

8
  1. Нет, когда вы собираетесь через Интернет вы не дело с ссылками, как вы, возможно, в C#, так что вы не сможете вернуть объект, который не сериализации. Даже тогда, только данных, что отмечено как DataMember столкнется.

  2. Да. Вы должны настроить известных типов, но опять-таки, что бы интерфейс к DataContract не OperationContract

+0

Я не ищу для сериализации интерфейсов или ссылок, но для установки дополнительных прокси и привязок, подобно тому, как это происходит по пути ChannelFactory.CreateChannel(), который был бы использован для установления исходного клиента для обслуживания соединения. – WaffleSouffle

+0

Я получаю это, но так работает WCF.Если вы хотите вернуть какую-либо услугу, это должен быть пользовательский объект с информацией об услуге (с инструкциями, как ее называть), в отличие от самой службы. Внутри, в коде, отличном от WCF, это работает, потому что вы передаете ссылки туда и обратно. За WCF это происходит не потому, что вы проходите статические экземпляры данных. Это МОЖЕТ быть возможным по именованным каналам, поскольку это проходит вокруг указателей памяти, но я скептически отношусь к тому, что это сработает. –

+0

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

0

Я не думаю, что это возможно. Когда вы вызываете метод в службе WCF, который принимает или возвращает объект, то на самом деле происходит то, что объект сериализуется, и сериализованная форма передается взад и вперед.

Именно поэтому на стороне клиента вы не получаете реализацию «полномасштабного» класса с атрибутом DataContract, но заглушку, которая содержит только свойства, помеченные для сериализации. Вы даже не получаете методы. Служба WCF присваивается как ServiceContract, а не как DataContract, так что это не сработает.

Возможность использования интерфейса передачи для метода услуги потребует, чтобы служба узнала, какая реализация должна быть десериализована. Хотя я на самом деле не пытался, я полагал, что это не сработает, но вы можете меня удивить здесь :-)

+0

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

+0

Я не думаю, что контракты обратного вызова работают именно так. Я предполагаю, что они не передают экземпляр службы обратного вызова, но клиент также настраивает службу WCF прозрачно. –

+0

Вы можете легко настроить дополнительные службы для существующего привязки. Вы можете просто объявить вторую службу в конфигурации, заставить ее использовать одну и ту же привязку, но добавить к URI. Например, ваш URI вашей первой службы является 'net.tcp: // localhost: 8080/MyService/Service1', вы можете просто иметь службу secon в URI' net.tcp: // localhost: 8080/MyService/Service2' (тот же порт, тот же базовый URI!). –