WCF и подтверждения - я должен передать обратно, 'хорошо получил его' клиенту?

Будьте принимают значение по умолчанию, Ваш сервис возвратит сообщение "OK" клиенту (даже если Ваш сервисный метод укажет пустой тип возврата), если исключение не выдается. Клиент будет ожидать, пока это не получит это сообщение перед продвижением с, он - жизнь.

Таким образом на основе Вашего вопроса Вы получаете поведение, которое Вы хотите по умолчанию.

Если бы Вы не хотите это, я согласился бы с Метелкой и отметил бы Вашу операцию как Один Путь (установка в Вашем контракте на операцию).

Удачи!

Существует три обменивающихся сообщениями шаблона, упомянутые здесь:

1. Синхронный ответ запроса
2. Асинхронный отправляют (запустите и забудьте с односторонним сервисом),
3. Асинхронный ответ запроса (дуплексный служебный вызов с односторонним сервисом)

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

Для Вашего требования возврата успеха клиенту, когда данные были сохранены к базе данных, опции 1 или 3 являются соответствующими.

Опция 1

Это - конфигурация по умолчанию.

Это возвращает 200 ответов на том же http соединении, после того как сервис выполнил все свои задачи. Это означает, что вызовы к сервису заблокируются при ожидании ответа - клиент зависнет, пока сервис не записал в базу данных и сделал что-либо еще, в чем это нуждается.

Опция 2

Возвращает 202 ответа, пока транспортный уровень и передающий уровень инфраструктуры успешно выполняется. Эти 202 возвратились, указывает, что сообщение было принято. От http rfc:

Запрос был принят для обработки, но обработка не была завершена. (...) 202 ответа намеренно уклончивы.

Это означает, что Ваш клиент продолжит выполнение, как только инфраструктура обслуживания успешно запустила сервис, и Вы не получите информации о том, успешно выполняется ли вызов базы данных или нет.

Опция 3

Подобный опции 2, ответ является http 202, не 200, но теперь при вызове сервиса от клиента, Вы обеспечиваете InstanceContext объект, который указывает объект обработать вызов назад. Клиент восстанавливает управление, и новый поток ожидает асинхронно сервисного ответа, сообщающего Вам об успешности или неуспешности.

Ниже еще некоторая информация о реализации этих шаблонов в WCF. После записи его он довольно длинен, но существует несколько полезных комментариев, а также код.

Как упомянутая Метелка, Juval Lowy имеет статью, касающуюся много этой детали (и больше!) здесь

Опция 1

Это - поведение по умолчанию в WCF, таким образом, Вы не должны должны быть делать что-либо - это работает с большой различной привязкой включая wsHttpBinding и basicHttpBinding.

Одна вещь отметить состоит в том, что поведение, описанное с Вашим клиентом, зависающим ожидающий 200 ответов, происходит, даже если Вы переносите пустую Операцию как так:

[ServiceContract]
interface IMyServiceContract
{
    [OperationContract]       
    void DoSomeThing(InputMessage Message);
}

Опция 2

Для установки операции, столь же односторонней, Вы просто украшаете его как так:

[ServiceContract]
interface IMyServiceContract
{
    [OperationContract(IsOneWay = true)]       
    void DoSomeThing(InputMessage Message);
}

Методы, украшенные таким образом, должны только иметь тип возврата пустоты. Один глюк - то, что сервис счастливо создаст, и Вы не получите исключение, говоря, что сервисная конфигурация недопустима, пока Вы не соединяетесь с ним.

Опция 3

Интерфейсный код для создания дуплексного сервиса обратного вызова:

[ServiceContract(CallbackContract = typeof(IMyContractCallback))]
interface IMyContract
{
    [OperationContract(IsOneWay=true)]       
    void DoSomeThing(InputMessage Message);
}

public interface IMyContractCallback
{
    [OperationContract(IsOneWay = true)]
    void ServiceResponse(string result);      
}

И на стороне клиента Вам нужно что-то как так для установки обратного вызова:

public class CallbackHandler : IMyContractCallback        
{
    #region IEchoContractCallback Members

    public void ServiceResponse(string result)
    {
        //Do something with the response
    }

    #endregion
}

// And in the client when you set up the service call:

InstanceContext instanceContext = new InstanceContext(new CallbackHandler());
MyContractClient client = new MyContractClient(instanceContext);

InputMessage msg = new InputMessage();

client.DoSomething(msg);           

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

class MyContractImplementation : IMyContract
{
    public void DoSomeThing(MyMessage Message)
    {

        string responseMessage;

        try
        {
           //Write to the database
           responseMessage = "The database call was good!";
        }
        catch (Exception ex)
        {
            responseMessage = ex.Message;
        }

        Callback.ServiceResponse(responseMessage);
    }
}

Одна важная вещь отметить, который ловил меня сначала, состоит в том, чтобы быть осторожна относительно исключений. Если Вы:

• Используйте исключение, Вы не получите предупреждения ошибки (но обратный вызов произойдет),

• Бросьте необработанное исключение, сервис завершится, и клиент даже не получит обратный вызов.

Это - один большой недостаток этого метода по сравнению с Опцией 1, Опция 1 возвратит исключение, когда необработанное исключение будет брошено.

Существует 2 способа, которыми Вы могли сделать, это - возвращает значение от Вашего вызова wcf, указывающего на успешность или неуспешность, или принимает успех и использует обратный вызов, чтобы сказать клиенту, если существует проблема.

Мое предпочтение состояло бы в том, чтобы использовать односторонний служебный вызов с дуплексным сервисом и использовать контракт на обратный вызов для сервиса для уведомления клиента отказа. Существует хорошее описание контрактов на обратный вызов здесь и здесь.

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

Я думаю, что вопрос мог использовать немного больше разработки для ответа правильно. Основной, какой тип привязки Вы в настоящее время используете?

При использовании привязки, которая поддерживает надежность, и Вы просто хотите быть уверенными от стороны клиента, что сервер действительно получал сообщение, то просто включают надежность, и Вы хороши. С этим на WCF, под капотом автоматически, будет иметь каждую сторону разговора, скажите: "Вы получили его?" "Я получил его. Вы получили его?" "Я получил его".