существует много причин, это - одна учетная запись, которая делает доступ ко всем. если это поставилось под угрозу, Вы входите в проблему.
при установке страницы, которая использует открытый, тогда необходимо знать, что все могут установить открытый сервер того (также спаммеры могут сделать это).
-
, но открытый имеет хорошие идеи, и мне нравится использовать его!
Я не на 100% понимаю, что вы пытаетесь сделать, но если вы просто хотите иметь возможность размещать разные контракты на одном и том же адресе с реализацией внутри одного класса обслуживания, это вполне возможно. Чтобы совместно использовать адрес конечной точки, вы должны убедиться, что вы используете один и тот же экземпляр привязки для каждой конечной точки службы.
Вот полный пример, который определяет 3 контракта, 1 класс службы, который реализует все из них, и ServiceHost с 3 контрактами конечные точки по одному и тому же адресу:
using System;
using System.ServiceModel;
[ServiceContract]
interface IContractA
{
[OperationContract]
void A();
}
[ServiceContract]
interface IContractB
{
[OperationContract]
void B();
}
[ServiceContract]
interface IContractC
{
[OperationContract]
void C();
}
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
class Service : IContractA, IContractB, IContractC
{
public Service()
{
}
public void A()
{
Console.WriteLine("A");
}
public void B()
{
Console.WriteLine("B");
}
public void C()
{
Console.WriteLine("C");
}
}
class Program
{
public static void Main(string[] args)
{
Uri address = new Uri("net.pipe://localhost/Service/");
ServiceHost host = new ServiceHost(new Service(), address);
NetNamedPipeBinding binding = new NetNamedPipeBinding();
host.AddServiceEndpoint(typeof(IContractA), binding, string.Empty);
host.AddServiceEndpoint(typeof(IContractB), binding, string.Empty);
host.AddServiceEndpoint(typeof(IContractC), binding, string.Empty);
host.Open();
IContractA proxyA = ChannelFactory<IContractA>.CreateChannel(new NetNamedPipeBinding(), new EndpointAddress(address));
proxyA.A();
((IClientChannel)proxyA).Close();
IContractB proxyB = ChannelFactory<IContractB>.CreateChannel(new NetNamedPipeBinding(), new EndpointAddress(address));
proxyB.B();
((IClientChannel)proxyB).Close();
IContractC proxyC = ChannelFactory<IContractC>.CreateChannel(new NetNamedPipeBinding(), new EndpointAddress(address));
proxyC.C();
((IClientChannel)proxyC).Close();
host.Close();
}
}
Я сомневаюсь, что это сработает. Сериализация XML может быть здесь самой большой проблемой.
Также я не думаю, что вам это действительно нужно. Если бы я был на вашем месте, я бы попытался абстрагироваться от общения с сервисом. По сути, вы всегда отправляете службе «Сообщение», в которой «Цель» является одним из классов, к которым вы хотите получить доступ. Служба всегда будет отвечать «Ответом», содержимое которого будет заполнено классом, которому было отправлено «Сообщение».
Другой подход заключается в маршрутизации всех этих сообщений через службу, которая будет повторять запрос на соответствующий сервис. Таким образом вы сохраняете масштабируемость, но при этом все еще требует большой нагрузки на конфигурацию.
HTH.
Похоже, вы хотите сохранить свои отдельные службы, но иметь какой-то автобус, который проходит через них. Может быть, MSMQ, тогда у вас может быть одна служба, которая принимает каждое сообщение, помещает его в определенную очередь, а затем выделенная служба может считывать это из этой конкретной очереди.
На самом деле это не решение на основе WCF, хотя по общему признанию.
Понятие о единый интерфейс (читаемый как ServiceContract), реализованный несколькими классами, работать не будет. Таким образом, вам понадобится один сервис-монстр, который реализует все и направляет к нужному сервису. На ум приходит узор фасада.