Какова лучшая практика при разработке веб-сервисов SOA WCF?

Question

Учитывая контракт на эксплуатацию, такой как:

[OperationContract]
void Operation(string param1, string param2, int param3);

Это может быть изменено на:

[MessageContract]
public class OperationRequest
{
    [MessageBodyMember]
    public string Param1 { get; set; }

    [MessageBodyMember]
    public string Param2 { get; set; }

    [MessageBodyMember]
    public int Param3 { get; set; }
}

[MessageContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

В MessageContract мне нравится то, что я получаю немного более четкий контроль над форматом сообщения SOAP.

Точно так же я мог бы написать почти такой же код, но использовать DataContract:

[DataContract]
public class OperationRequest
{
    [DataMember]
    public string Param1 { get; set; }

    [DataMember]
    public string Param2 { get; set; }

    [DataMember]
    public int Param3 { get; set; }
}

[DataContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

В DataContract мне нравится то, что я могу определять IsRequired, Order и Name.

Сегодня я ожидаю, что единственным потребителем будет клиент WCF. Тем не менее, я хочу сначала разработать контракт и максимально придерживаться принципов SOA. Вместо того чтобы WCF определял мои SOAP, WSDL и XSD, я хочу, чтобы XML определял уровень WCF, но использую WCF для его генерации, чтобы не добавлять какую-либо настраиваемую обработку сообщений в WCF. Я хочу следовать наиболее распространенным соглашениям SOA XML, которые, как я полагаю, вероятно, все теги начинаются со строчной буквы - я прав? И я хочу быть максимально зависимым от версии.

Разумно ли всегда создавать подобные сообщения с запросами и ответами? Какой из трех форматов продвигает лучшие практики SOA? Должен ли я пойти еще дальше и определить и DataContract, и MessageContract, при этом MessageContract содержит только DataContract? Или я должен когда-либо использовать DataContracts, только если я действительно выставляю новый тип (т.е. не создаю типы сообщений как контейнеры)?

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

Answer 1

XML обычно имеет тенденцию быть верблюжьей. WSDL и SOAP Схема использует camelCasing как для элементов, так и для атрибутов, например, проверьте синтаксис и схема .

Почему WS* было определено по-другому, я не знаю, но он использует PascalCasing для элементов и camelCasing для атрибутов, проверьте здесь .

Аналогично, большинство SOA спецификаций (возможно, всех) используют PascalCasing для элементов и атрибутов, см. здесь . Схема XML не зависит от соглашений типов, которые она определяет для XML.

Томас Эрл пишет много важных книг на WCF , включая " Сервис-ориентированная архитектура " ;. В главах 13 и 15 он приводит ряд примеров XML различных частей типичных транзакций. Он определяет типы и члены объекта в XML-схеме, используя PascalCasing, который хорошо соответствует обычным шаблонам C # для именования классов и свойств. Таким образом, OperationContract значения по умолчанию уже близко соответствуют стандартам.

Что касается фактического именования сообщений, в некоторых соглашениях используется camelCasing, а в других - PascalCasing, поэтому я предпочитаю соответствовать основным языковым потребностям, в случае DataContract это PascalCasing. И MessageContract значения по умолчанию соответствуют некоторым примерам того, как следует написать сообщение с запросом и ответом, некоторые примеры здесь .

Таким образом, единственным нерешенным вопросом в настоящее время является основной вопрос о том, сколько стандартизировать вокруг использования XSD, <=> и / или <=>.

Определение DataContract только тогда, когда у вас есть сложный тип (на языке <=>), имеет смысл, и я склонен думать, что YAGNI (вам это не нужно), как указал Терри, является правильным выбором, но < em> Erl , похоже, предлагает гораздо более интенсивную версию, поэтому я все еще не уверен, какой вариант лучше использовать в качестве выбора по умолчанию (основная часть вопроса).

Answer 2

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

Я работаю в команде по интеграции бизнеса, где мы довольно регулярно интегрируемся с другими компаниями (AT & amp; T, Cox, Exxon ...) и никогда не видели вызова веб-службы, который принимал бы более одного параметра .

Answer 3

Я думаю, что это честно зависит от сценария. Если вы просто обмениваетесь простыми типами [т.е. string], OperationContract, безусловно, допустим.

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

Answer 4

YAGNI приходит на ум.

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