Шаблон запроса / ответа в реализации SOA - PullRequest
Новая
       0

Шаблон запроса / ответа в реализации SOA

17 голосов
/ 16 июня 2010

В каком-то корпоративном проекте (.NET, WCF) я увидел, что все сервисные контракты принимают один параметр Request и всегда возвращают Response: 

[DataContract]
public class CustomerRequest : RequestBase {
        [DataMember]
        public long Id { get; set; }
}

[DataContract]
public class CustomerResponse : ResponseBase {
        [DataMember]
        public CustomerInfo Customer { get; set; }
}

, где RequestBase/ResponseBase содержит такие общие вещи, как ErrorCode, Context и т. Д. Тела как служебных методов, так и прокси обернуты в try / catch, поэтому единственный способ проверить ошибки - это посмотреть ResponseBase.ErrorCode (это перечисление) .

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

1 Ответ

28 голосов
/ 17 июня 2010

Шаблон, о котором вы говорите, основан на разработке Contract First. Однако не обязательно использовать шаблон блока ошибок в WCF, вы все равно можете выдавать исключения ошибок клиенту вместо использования блока Error Xml. Блок Error использовался в течение очень долгого времени, и поэтому многие люди привыкли к его использованию. Кроме того, другие разработчики платформы (например, java) не так хорошо знакомы с faultExceptions, хотя это промышленный стандарт.
http://docs.oasis -open.org / WSRF / WSRF-ws_base_faults-1,2-спец-os.pdf

Шаблон запроса / ответа очень важен в SOA (сервис-ориентированная архитектура), и я бы рекомендовал использовать его, а не создавать методы, которые принимают параметры и возвращают значение или объект. Вы увидите преимущества, когда начнете создавать свои сообщения. Как указывалось ранее, они произошли от разработки контракта в первую очередь, где сначала нужно создавать сообщения с использованием XSD и генерировать ваши классы на основе XSD. Этот процесс использовался в классических веб-сервисах для обеспечения правильной сериализации всех типов данных в SOAP. С появлением WCF, datacontractserializer стал более интеллектуальным и знает, как сериализовать типы, которые ранее не сериализуются должным образом (например, ArrayLists, List и т. Д.).

Преимущества шаблона запроса-ответа:

  • Вы можете наследовать все свои запросы и ответы от базовых объектов, где вы можете поддерживать согласованность общих свойств (например, блок ошибок).
  • Веб-службы по своей природе должны требовать как можно меньше документации. Эта модель позволяет только это. Возьмем, к примеру, метод, подобный public BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest request);. По умолчанию клиент будет знать, что передавать, и что он получает, а также, когда он создает запрос, он может видеть, что требуется, а что необязательно. Скажем, у этого запроса есть такие свойства, как Carriers [Flag Enum] (Обязательный), StartDate (Обязательный), EndDate (Обязательный), PriceRange (необязательный), MinSeatsAvailable (Опциональный) и т. Д ... Вы получите точку.
  • Когда пользователь получил ответ, он может содержать намного больше данных, чем просто обычный возвращаемый объект. Блок ошибок, отслеживание информации, что угодно, используйте свое воображение.
    В примере BusScheduleResponse это может вернуть несколько массивов информации о расписании автобусов для нескольких перевозчиков.

Надеюсь, это поможет.

Одно слово предостережения. Не смущайтесь и подумайте, что я говорю о создании ваших собственных [MessageContract] s. Ваши запросы и ответы являются DataContracts. Я просто хочу убедиться, что я вас не смущаю. Никто не должен создавать свои собственные MessageContracts в WCF, если у них нет веских причин для этого.

...