Добавляет ли метод WCF ServiceContract нарушать существующие клиенты?

У нас есть существующий ServiceContract

[ServiceContract(Namespace = "http://somesite.com/ConversationService")]
public interface IConversationService
{
        [OperationContract(IsOneWay = true)]
        void ProcessMessage(Message message);

        [OperationContract(IsOneWay = true)]
        void ProcessMessageResult(MessageResult result);
}

и нам нужно добавить к нему метод

[ServiceContract(Namespace = "http://somesite.com/ConversationService")]
public interface IConversationService
{
        [OperationContract(IsOneWay = true)]
        void ProcessMessage(Message message);

        [OperationContract(IsOneWay = true)]
        void ProcessMessageResult(MessageResult result);

        [OperationContract(IsOneWay = true)]
        void ProcessBlastMessage(BlastMessage blastMessage);
}

Будет ли это нарушать любые существующие wcf-клиенты, которые используют эту услугу? Или нам нужно обновить все существующие wcf-клиенты?

EDIT: эта служба использует как netTcpBinding, так и netMsmqBinding

Ответ 1

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

Я только проболтался в WCF, но использовал веб-службы ASP.NET таким образом, чтобы добиться больших успехов.

Ответ 2

Нет, я бы не ожидал, что добавление новых функциональных/новых методов обслуживания, которые НЕ изменят ни один из существующих вызовов методов/функций, не повлияет на "старых" клиентов. Конечно, они не будут знать о новых методах, пока их прокси не будут воссозданы из метаданных или не будут адаптированы вручную.

Но существующие вызовы не должны затрагиваться, пока их подпись (данные, которые они обменивают) остается неизменной.

Марк

Ответ 3

В общем, добавление сообщения в SOA-решения не нарушает контракт. Я считаю, что до тех пор, пока вы не используете бинарный протокол (net.tcp), вы будете поддерживать обратную совместимость.

Я не уверен, будет ли он разбивать ваши клиенты, используя бинарные привязки, хотя?

Ответ 4

Я принимаю более экстремальный взгляд на это. Зачем что-то менять? Вместо этого, почему бы не создать новый контракт, наследующий от старого, и добавить новую операцию? Новый контракт может быть выставлен в отдельной конечной точке в той же службе.

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

Существующий клиент будет ссылаться на исходную конечную точку, поэтому на нее не будет влиять добавление новой конечной точки - никакой код не изменится, если была выполнена "ссылка на службу обновлений".

Кроме того, зачем даже думать об этом, если вам не нужно?

Ответ 5

Я только что протестировал это с помощью приложения Windows WCW (UWP) и продолжал работать после обновления сервисного приложения WCF. Таким образом нет: как было сказано ранее, ваши клиенты не будут ломаться при добавлении метода.

Я подумал, что стоит упомянуть, как легко обновить клиентских сервисов с помощью Visual Studio 2015:

Убедитесь, что ваша служба WFC запущена.
Просто перейдите к Solution Explorer,
Развернуть Service References
Щелкните правой кнопкой мыши ссылку на службу
Нажмите Update Service Reference
Если вы получили сообщение об ошибке, повторите последний шаг. По какой-то причине мне пришлось попробовать несколько раз.