Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
(что, опять?)
Пожалуйста, объясните, что вы имеете в виду под «Сервис должен быть повторно используемым». Какая именно часть сервиса должна быть повторно используемой и зачем?
Каким образом в этой реализации предполагается обмен метаданными и их валидация?
Пожалуйста, объясните, что вы имеете в виду под «Сервис должен быть повторно используемым». Какая именно часть сервиса должна быть повторно используемой и зачем?
Каким образом в этой реализации предполагается обмен метаданными и их валидация?
Обмен мета-данными, предположу:
Нет конкретных объектов в методах сервиса, нет атрибутов включающих их на уровне родителя, нет GetKnowTypes. Никак.
Универсальность в SOA, в таком виде, для большинства проектов, сильна сомнительна.
По поводу контрактов операций, то количество операций там не должно превышать 3-5, это эмпирически.
Подход имеет право на жизнь, когда пишется иерархия Message и его наследников, после чего через специальные вызовы или атрибуты успешно реализуется мета-информация, а в методе исполнения фабрика обработки запросов. Делали так для игровых проектов, где много небольших событий, вроде бы все похожи, но чуть-чуть да разные.
Нет конкретных объектов в методах сервиса, нет атрибутов включающих их на уровне родителя, нет GetKnowTypes. Никак.
Универсальность в SOA, в таком виде, для большинства проектов, сильна сомнительна.
По поводу контрактов операций, то количество операций там не должно превышать 3-5, это эмпирически.
Подход имеет право на жизнь, когда пишется иерархия Message и его наследников, после чего через специальные вызовы или атрибуты успешно реализуется мета-информация, а в методе исполнения фабрика обработки запросов. Делали так для игровых проектов, где много небольших событий, вроде бы все похожи, но чуть-чуть да разные.
Вот и мне кажется, что формализованного обмена метаданными тут нет, со всеми вытекающими отсюда проблемами. Это не «стабильный и универсальный интерфейс», это «отсутствие формального интерфейса».
Тут видимо человек предполагает, что у него все проекты — однотипные, сообщения он и получает и отправляет. Т.е. это всегда команда, у которых один source control и т.д. Мне кажется, в этом есть своя прелесть, но я бы все равно реализовывал через Message и наследование. С другой стороны, а зачем тогда вообще использовать WCF? SOA это ведь отдельные независимые сервисы, которые хоть как-то миру сообщают, кто они и что они.
Ну, скажем, SOA-то никто и не заявлял. Но ценность подобного подхода мне и правда не понятна; по крайней мере, я так и не смог найти сценария, где от него был бы существенный выигрыш.
Не, ServiceStack — не интересно. У них реализация такова, что внутри — message-based, а снаружи можно выставить типизованный контракт тем не менее.
Ну и достоинства они описывают, прямо скажем, не message-based, а своего «гениального» стека. Потому что вообще-то WCF тоже message-based, поэтому было бы сложно так выделиться.
Так что вернемся к вопросу: каковы достоинства конкретного приведенного в этом посте подхода?
Ну и достоинства они описывают, прямо скажем, не message-based, а своего «гениального» стека. Потому что вообще-то WCF тоже message-based, поэтому было бы сложно так выделиться.
Так что вернемся к вопросу: каковы достоинства конкретного приведенного в этом посте подхода?
В линках, как я уже говорил, ничего особенного не написано. А своими словами вы изложить не можете?
А подход-то похож, да только какой в нем смысл, если есть ServiceStack, в котором реализовано нормально?
А подход-то похож, да только какой в нем смысл, если есть ServiceStack, в котором реализовано нормально?
прочитайте — готов обсудить,
Прочитал. Давайте обсуждать. В чем преимущества?
Понимаете ли, в чем дело… я не понимаю, как статья относится к тому, что в посте. Статья полемизирует с неким абстрактным WCF-в-вакууме (хотя WCF прекрасно позволяет делать Message Contracts, в документации это описано). Пост же полемизирует вообще непонятно с чем, но зато предлагает выставлять сервисы, не имеющие метаданных.
Поэтому давайте вернемся к началу: какие именно преимущества из описанных в статье (назовите хотя бы три) реализуются подходом, описанным в статье, и при этом не реализуются обычными Message Contract в WCF?
При этом назвать недостаток у предложенного в посте подхода я могу легко: по описанному сервису невозможно получить типизованный контракт, что делает невозможной автоматическую генерацию клиентов (у ServiceStack этого недостатка нет, у них свой механизм формирования метаданых).
Поэтому давайте вернемся к началу: какие именно преимущества из описанных в статье (назовите хотя бы три) реализуются подходом, описанным в статье, и при этом не реализуются обычными Message Contract в WCF?
При этом назвать недостаток у предложенного в посте подхода я могу легко: по описанному сервису невозможно получить типизованный контракт, что делает невозможной автоматическую генерацию клиентов (у ServiceStack этого недостатка нет, у них свой механизм формирования метаданых).
Я так понимаю, что вы не можете сказать, какие преимущества подхода, описанного у ServiceStack, применимы к тому, что пишет автор поста?
(про достоинства самого сервис-стека я бы поговорил где-нибудь в другом месте, а приписывать их тому, что описано здесь — не надо)
(про достоинства самого сервис-стека я бы поговорил где-нибудь в другом месте, а приписывать их тому, что описано здесь — не надо)
Окей, пойдем с другой стороны.
Я хочу заметить, что plain vanilla WCF — он message-based. Правильно ли я понимаю, что все описанные «advantages of message based web services» к нему равно применимы? Если нет, то какие не применимы, и почему?
(подход «похож» у всех WS-фреймворков, растущих из SOAP)
Я хочу заметить, что plain vanilla WCF — он message-based. Правильно ли я понимаю, что все описанные «advantages of message based web services» к нему равно применимы? Если нет, то какие не применимы, и почему?
(подход «похож» у всех WS-фреймворков, растущих из SOAP)
Во-первых, это банальное жульничество. Любой сервисный фреймворк на .net маппит операции на методы (включая service stack); при этом никто не мешает в WCF сделать сервис хоть с одной операцией, а аргументом этой операции все равно является сообщение.
И это, собственно, приводит нас к вопросу: так какое именно достоинство из перечисленных в статье недоступно WCF?
(ваша конкретная цитата вообще относится к предлагаемому разработчикам стилю письма, а не к реальным возможностям/недостаткам)
И это, собственно, приводит нас к вопросу: так какое именно достоинство из перечисленных в статье недоступно WCF?
(ваша конкретная цитата вообще относится к предлагаемому разработчикам стилю письма, а не к реальным возможностям/недостаткам)
Удивительно, что вы не видите: то, чего вы хотите — это и есть маппинг на методы; вы хотите от WCF, чтобы при приходе определенного сообщения вызывался определенный метод… это ли не маппинг на методы? И я не знаю фреймворка, в котором это было бы иначе, почему и говорю, что утверждение «ошибочное решение с маппингом на методы» — жульничество (особенно от создателей фреймворка, в котором названия методов определены соглашением).
А теперь давайте, как вы говорите, «разбираться в технологиях».
Описанное вами ограничение (уникальности именования) — это не особенность WCF, это требование WSDL (который, на минуточку, industry standard, краеугольный камень SOA и так далее). WSDL требует, чтобы операции в рамках одного port имели уникальные имена. И WSDL же говорит, что у одной операции ровно один тип входного сообщения. Как следствие, WCF — который изначально писался как WS*-совместимый фреймворк — налагает то же ограничение на реализуемые сервисы. Собственно говоря, вы сам допускаете ошибку «маппинга на методы», которую приписываете WCF — вы оперируете понятиями «метод» и «перегрузка», которых в SOA просто нет. Если бы вы мыслили в терминах стандартов, у вас бы не возникло таких странных требований.
Но предположим у вас есть потребность в поведении, при котором одна и та же операция может получать на вход более одного разного типа данных, и обрабатывать их по-разному в зависимости от типа. Это поведение достижимо в WCF как минимум двумя разными способами, с различной степенью вмешательства в инфраструктуру.
А теперь давайте, как вы говорите, «разбираться в технологиях».
Описанное вами ограничение (уникальности именования) — это не особенность WCF, это требование WSDL (который, на минуточку, industry standard, краеугольный камень SOA и так далее). WSDL требует, чтобы операции в рамках одного port имели уникальные имена. И WSDL же говорит, что у одной операции ровно один тип входного сообщения. Как следствие, WCF — который изначально писался как WS*-совместимый фреймворк — налагает то же ограничение на реализуемые сервисы. Собственно говоря, вы сам допускаете ошибку «маппинга на методы», которую приписываете WCF — вы оперируете понятиями «метод» и «перегрузка», которых в SOA просто нет. Если бы вы мыслили в терминах стандартов, у вас бы не возникло таких странных требований.
Но предположим у вас есть потребность в поведении, при котором одна и та же операция может получать на вход более одного разного типа данных, и обрабатывать их по-разному в зависимости от типа. Это поведение достижимо в WCF как минимум двумя разными способами, с различной степенью вмешательства в инфраструктуру.
ибо такие же ограничение есть и в REST на WCF
REST — это совсем другое дело, не надо его сюда тащить. Пост — про SOAP.
по больше части абсолютно все равно чье это ограничение.
Отнюдь. Если это ограничение парадигмы, то надо менять парадигму, а не продолжать есть этот невкусный кактус.
читайте статью про преимущества MessageBased подхода… :)
Это не связанные вещи. Message-based прекрасно делается другими способами.
По мне «операцию» лучше передавать «командной», ибо сам по себе метод например «Process» большого толку не имеет, смысл появляется если написать полную сигнатуру…
Так это же вы выдумали этот метод, а не я. В контрактах моих сервисов таких методов не бывает.
а если передаваемые данные представлять в виде команд или запросов, то повторноиспользуемость + полиморфизм сделают свое дело…
Можете привести конкретный пример сценария, где это было бы выигрышно, и где реально работал бы полиморфизм и было повторное использование чего бы то ни было, и при этом тот же эффект не был бы достижим в plain WCF разумными усилиями?
более подробно можно почитать здесь martinfowler.com/bliki/CQRS.html
Омг, вот только CQRS сюда не привлекайте. Пойдите и прочитайте Грега Янга, там явно сказано: для CQRS не нужен messaging.
Смотрю как только арумент не подходит, сразу **** типа
Если аргумент не относится к теме — он действительно не подходит.
ServiceStack не интересно, потому что пост про WCF. REST не интересно, потому что пост про SOAP. И то, и другое написано в заголовке поста.
Я так понимаю, привести конкретный пример, запрошенный выше, вы не можете или не считаете нужным?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Построение SOAP веб-сервисов, основанных на сообщениях, с помощью WCF