Share via

Использование конечных точек службы

  • Статья

Дата последнего изменения: 15 февраля 2011 г.

Применимо к: SharePoint Foundation 2010

В этой статье
Поддерживаемые протоколы
Определение конечных точек службы
Предоставление нескольких конечных точек
Определение конечных точек в коде инициализации службы
Определение конечных точек в конфигурации клиента
Определение конечных точек в коде прокси-сервера

Все взаимодействие со службой Windows Communication Foundation (WCF) происходит через конечные точки службы. Конечная точка службы задает контракт, определяющий, какие методы класса службы могут быть доступны через конечную точку, и каждая конечная точка может предоставлять разные наборы методов. Конечные точки также определяют привязку, которая указывает способ взаимодействия клиента со службой и сетевой адрес размещения конечной точки.

Поддерживаемые протоколы

приложений-служб поддерживает все поддерживаемые в WCF протоколы, однако для конечных точек службы рекомендуется использовать протоколы HTTP и HTTPS:

  • HTTP

  • HTTPS

    ПримечаниеПримечание

    приложений-служб автоматически устанавливает и настраивает SSL-сертификат для конечных точек службы HTTPS. В пользовательском интерфейсе управления службами IIS этот сертификат не отображается, но он устанавливается. Установку можно проверить, выполнив в командной строке следующую команду:

    netsh http show sslcert ipport=0.0.0.0:32844

Определение конечных точек службы

Каждая конечная точка, поддерживаемая приложением-службой WCF, должна быть определена в параметрах web.config для приложения. Протокол и адрес каждой конечной точки должны быть уникальными. Например, у двух конечных точек может быть одинаковый адрес, если в их соответствующих привязках заданы разные протоколы. Однако если для двух конечных точек используется один протокол, для них должны быть заданы разные адреса.

Используйте уникальный адрес для каждой конечной точки, чтобы эти адреса не зависели от связывающего протокола. Укажите адрес конечной точки относительно базового адреса, заданного в приложений-служб.

Например, чтобы задать две конечные точки с относительными адресами "http" и "https", воспользуйтесь следующим кодом.

<services>
    <service
        name="Microsoft.SharePoint.Test.SampleWebServiceApplication">
        <endpoint
          address="http"
          contract="Microsoft.SharePoint.Test.ISampleWebServiceContract"
          binding="customBinding"
          bindingConfiguration="SampleWebServiceHttpBinding" />
        <endpoint
          address="https"
          contract="Microsoft.SharePoint.Test.ISampleWebServiceContract"
          binding="customBinding"
          bindingConfiguration="SampleWebServiceHttpsBinding" />
      </service>
    </services>

Если базовый адрес службы в предыдущем примере равен http://machine:8080/application/calculator.svc, то адреса конечных точек равны:

http://machine:8080/application/calculator.svc/http

http://machine:8080/application/calculator.svc/https

Предоставление нескольких конечных точек

Приложение-служба может поддерживать две конечные точки: одну с привязкой, оптимизированной для производительности (где, например, сетевой трафик между интерфейсным веб-сервером и сервером приложений проходит по закрытой локальной сети и не требует шифрования), и одну с привязкой, оптимизированной для безопасности (где сетевой трафик должен шифроваться). приложений-служб предоставляет пользовательский интерфейс, позволяющий администратору фермы выбирать конечную точку, наиболее подходящую для топологии сети. Администраторы могут управлять выбором конечных точек с помощью параметра Публикация на странице "Управление приложением-службой" сайта центра администрирования или с помощью параметра DefaultEndpoint командлета Set-SPServiceApplication Windows PowerShell.

Определение конечных точек в коде инициализации службы

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

Используйте метод AddServiceEndpoint в SPIisWebServiceApplication, как показано в следующем примере.

// Construct your SPIisWebServiceApplication derived class as usual.
MyWebServiceApplication app = new MyWebServiceApplication(…);

// Commit the new application to the configuration database.
// NOTE: Update must be called before AddServiceEndpoint.

// The service application must be committed to the configuration database before endpoints can be added.
app.Update();

// Add the endpoints supported by the application.
// NOTE: AddServiceEndpoint should be called before app.Provision, because app.Provision will provision 
// the default HTTP endpoint if no endpoints are explicitly added to the application.
// NOTE: The default endpoint name is always "http"
app.AddServiceEndpoint("", SPIisWebServiceBindingType.Http);

// Add an alternate HTTPS endpoint.
app.AddServiceEndpoint("secure", SPIisWebServiceBindingType.Https);

Конечная точка с именем "http" используется в качестве конечной точки по умолчанию для приложения-службы. Имя конечной точки службы должно быть уникальным, даже если адреса конечных точек не уникальны. При наличии двух конечных точек в одном относительном адресе необходимо использовать третий необязательный параметр AddServiceEndpoint для задания относительного адреса. Третий параметр по умолчанию равен имени конечной точки.

В следующем примере показано определение двух конечных точек в одном базовом адресе службы, для первой из них используется протокол HTTP, а для второй — HTTPS. Конечная точка https находится в базовом адресе службы "".

app.AddServiceEndpoint("", SPIisWebServiceBindingType.Http); 
// The default endpoint.
app.AddServiceEndpoint("https", SPIisWebServiceBindingType.Https, "");

Определение конечных точек в конфигурации клиента

Каждая конечная точка также должна быть определена в конфигурации клиента. Создайте файл client.config с привязками, соответствующими файлу web.config для приложения-службы. У каждой конечной точки клиента должно быть уникальное значение атрибута name, чтобы на нее можно было ссылаться из кода прокси-сервера, который будет считывать файл конфигурации, как показано в следующем примере.

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

<configuration>
  <system.serviceModel>
    <client>
      <endpoint
        name="http"
        contract="Microsoft.SharePoint.Test.ISampleWebServiceContract"
        binding="customBinding"
        bindingConfiguration="SampleWebServiceHttpBinding" />
      <endpoint
        name="https"
        contract="Microsoft.SharePoint.Test.ISampleWebServiceContract"
        binding="customBinding"
        bindingConfiguration="SampleWebServiceHttpsBinding" />
    </client>

Определение конечных точек в коде прокси-сервера

В коде прокси-сервера с помощью соответствующей конфигурации конечной точки должна создаваться фабрика канала. Конфигурация конечной точки определяется по имени (атрибут name элемента конфигурации клиента endpoint). Чтобы определить имя конфигурации конечной точки, просмотрите URI конечной точки перед созданием канала и сравните относительный адрес с известными адресами конечных точек. Код, используемый для кэширования клиентской фабрики канала, показан в следующем примере. Если адреса конечных точек различаются только протоколом, при сравнении воспользуйтесь схемой URI.

private string m_EndpointConfigurationName;
private ChannelFactory<ISampleWebServiceContract> m_ChannelFactory;
private object m_ChannelFactoryLock = new object();

Извлеките имя конфигурации конечной точки для заданного адреса конечной точки.<param name="address">The endpoint address.</param>

GetEndpointConfigurationName возвращает имя конечной точки. Возвращенное имя конечной точки должно совпадать с одним из имен элементов конечной точки в файле client.config.

private string GetEndpointConfigurationName(Uri address)
{
    if (null == address)
    {
        throw new ArgumentNullException("address");
    }
    if (address.Scheme == Uri.UriSchemeHttp)
    {
        return "http";
    }

    if (address.Scheme == Uri.UriSchemeHttps)
    {
        return "https";
    }
    return String.Empty;
}
private ISampleWebServiceContract GetChannel(Uri address)
{
    // Create an endpoint address for the service.
    EndpointAddress endpointAddress = new EndpointAddress(address); 

    // Get the endpoint configuration name.
    string endpointConfigurationName = GetEndpointConfigurationName(address); 
    // Check for a cached channel factory for the endpoint configuration.
    if ((null == m_ChannelFactory) || 
    (endpointConfigurationName != m_EndpointConfigurationName))
    {
        lock (m_ChannelFactoryLock)
        {
            if ((null == m_ChannelFactory) || 
               (endpointConfigurationName != m_EndpointConfigurationName))
            {

                // Create a channel factory
                // endpoint configuration name.
                m_ChannelFactory = 
                CreateChannelFactory<ISampleWebServiceContract>
                (endpointConfigurationName);
                // Store the current endpoint configuration name.
                m_EndpointConfigurationName = endpointConfigurationName;
            }
        }
    }
    // Create a channel from the channel factory.
    return m_ChannelFactory.CreateChannel(endpointAddress);
}
ПримечаниеПримечание

Если фабрика канала помещена в кэш, его следует объявить недействительным.

См. также

Концепции

Создание веб-служб платформы приложений-служб