WCF: отдельные методы или общий метод ProcessMessage, принимающий XML

Question

Моя компания разрабатывает приложение, которое получает данные от другой компании через сокеты TCP и сообщения xml. Это доставляется одному приложению-шлюзу, которое затем передает его нескольким копиям одного и того же внутреннего приложения на разных компьютерах в нашей организации.

WCF был выбран в качестве технологии для обработки внутренних коммуникаций (внутренне двунаправленная). Разработчики рассмотрели два метода.

1. Индивидуальные методы, предоставляемые WCF сервис для каждого отдельного сообщение получено шлюзом приложение. Шлюз приложение будет анализировать входящие внешнее сообщение и позвоните соответствующий метод обслуживания WCF. входящий XML будет переведен в DataContract DTO и поставляются в качестве аргумента для соответствующего WCF способ.

2. Внутреннее приложение выставил сервис WCF с одним метод «ProcessMessage», который принял текстовое сообщение XML как аргумент. Внутреннее приложение будет разобрать и десериализовать полученный xml и обработайте его соответственно.

Ведущий разработчик подумал, что второй вариант - лучший вариант, так как «легче» сериализовать / десериализовать xml. Я думал, что аргумент не имеет смысла, потому что DataContracts сериализуются и десериализуются WCF, и с помощью WCF нам удалось лучше типизировать наши данные. В варианте 2 кто-то может вызвать службу WCF и передать любую строку. Я полагаю, что вариант 1 представляет более удобный интерфейс и делает приложение более легким в обслуживании и использовании.

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

Мне было интересно, каковы нынешние мысли о передаче такого рода информации и мнения людей об обеих альтернативах.

Answer 1

Вариант 1 подходит, если вы можете гарантировать, что клиент всегда отправляет сериализованные представления контрактов данных на сервер.

Однако, если вам нужна некоторая гибкость в логике сериализации / десериализации и нет тесной связи с DataContracts, тогда вариант 2 выглядит хорошо. Особенно полезно, когда вы хотите поддерживать альтернативные формы XML (например, представления Atom, необработанный XML в произвольном формате и т. Д.)

Также в варианте 2 внутри метода ProcessMessage () у вас есть возможность решить , следует ли десериализовать входящую полезную нагрузку xml (на основе заголовков запросов или чего-то определенного для вашего приложения).

В варианте 1 среда выполнения WCF всегда десериализует полезную нагрузку.

Answer 2

Я недавно задал пару вопросов по этой области: XML против объектов и XML против объектов # 2 . Вы найдете интересные ответы на эти вопросы.

Для нашей конкретной проблемы мы выбрали гибридный подход, интерфейс которого выглядит примерно так:

// Just using fields for simplicity and no attributes shown.
interface WCFDataContract
{
    // Header details
    public int id;
    public int version;
    public DateTime writeDateTime;

    public string xmlBlob;

    // Footer details
    public int anotherBitOfInformation;
    public string andSoemMoreInfo;
    public book andABooleanJustInCase;

}

Причина, по которой мы используем xmlBlob, заключается в том, что мы владеем схемой верхнего и нижнего колонтитула, а не большим двоичным объектом в середине. Кроме того, нам не нужно обрабатывать этот BLOB-объект, мы просто передаем его в другую библиотеку (созданную другим отделом). Другая библиотека возвращает нам более строго типизированные данные.

Удачи - из опыта я знаю, что ваш вариант 2 может быть весьма соблазнительным, и иногда с ним трудно поспорить, не будучи обвиненным в чрезмерной чистоте и недостаточно прагматичном;)

Answer 3

Надеюсь, я правильно понял. Я думаю, что может иметь смысл, чтобы ваше приложение шлюза обрабатывало всю десериализацию, и чтобы ваше внутреннее приложение предоставляло сервисы WCF, которые принимают фактические объекты DataContract.

Таким образом, ваша десериализация XML-кода на основе TCP более централизована на шлюзе, и вашим внутренним приложениям не нужно беспокоиться об этом, им просто нужно показывать все службы WCF, которые имеют смысл, и могут иметь дело с реальными объекты.

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

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