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

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

11 голосов
/ 24 января 2009

С учетом контракта на эксплуатацию, например: 

[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, только если я действительно выставляю новый тип (т.е. не создаю типы сообщений как контейнеры)?

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

Ответы [ 4 ]

15 голосов
/ 26 июня 2009

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

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

6 голосов
/ 02 февраля 2009

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

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

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

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

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

Таким образом, единственным нерешенным вопросом является теперь основной вопрос о том, сколько стандартизировать вокруг использования OperationContract, DataContract и / или MessageContract.

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

0 голосов
/ 26 января 2009

ЯГНИ приходит на ум здесь.

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

0 голосов
/ 26 января 2009

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

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

...