Служба WCF, предоставляющая конечные точки REST / HTTP и именованных каналов

Question

Я нахожусь в процессе создания набора служб .Net 4.0 WCF, к которым будет обращаться приложение на основе браузера ASP.NET MVC3, и я ищу комментарии / предложения / примеры по следующему подходу.Вот наш сценарий:

Первоначальный рендеринг страниц приложения браузера требует значительной логики на стороне сервера из-за разрешений и конфигурации.Серверный код приложения браузера должен получить доступ к службам WCF, чтобы правильно отобразить исходный HTML / JavaScript.Мы бы предпочли принять начальный рендеринг на стороне сервера, чем вытолкнуть управляющий скелет, и у браузера возникла проблема с AJAX-вызовами для начального состояния.

Как только HTML возвращается клиенту, клиентские взаимодействия с приложением будутинициировать вызовы AJAX к службам WCF - часто к тем же службам, к которым обращались во время рендеринга на стороне сервера.

Мы также хотим, чтобы определенные методы служб WCF представляли собой интерфейс RESTful для третьих сторон.

Понимая, что мы также можем использовать ASP.Net MVC для предоставления службы RESTful, предпочтительно использовать компонент служб WCF для обеспечения будущей масштабируемости - в конечном итоге мы можем захотеть запустить бизнес-службы независимо в ферме серверов.

Поскольку в одном и том же экземпляре IIS будут размещаться как веб-сайт, так и служба WCF, для серверного кода для вызовов службы WCF, я думаю, мы добьемся некоторой производительности, используя транспорт именованных каналов и двоичное кодирование, нопотому что мы будем использовать AJAX и интернет-анВ состоянии API, мы также должны предоставить сервис RESTful.

Мне кажется, что существует множество примеров сервисов RESTful для WCF .Net 4.0, но ни один из них не использует несколько конечных точек с различными транспортными средствами, а примеры .Net 3.5, которыеиспользование JSON поверх HTTP, по-видимому, плохо переводится в пространство .Net 4.0.

Мысли / руководство?Заранее спасибо.

Answer 1

Я не уверен, действительно ли вы хотите использовать именованные каналы и двоичные протоколы в вашем проекте.Это довольно старая технология, и она не готова к работе в Интернете.Производительность, которую вы можете получить с помощью двоичного кодирования, может не стоить потери масштабируемости.При возникновении проблем с производительностью обычного API RESTful HTTP без сохранения состояния вы можете поставить перед ним балансировщик нагрузки и масштабировать его на несколько блоков.Я не уверен, возможно ли даже сбалансировать нагрузку службы, доступной через именованные каналы.

Я пытался использовать WCF для реализации JSON REST API.В теории все выглядит хорошо, но WCF - большая пушка, ее не стоит использовать для отстрела мухи.В любом случае, поиграв некоторое время с WCF (и застревая при реализации аутентификации на основе файлов cookie), я получил довольно простое решение, которое я описал здесь http://blog.lome.pl/mvc/implementing-asp-net-mvc-rest-api/

Answer 2

Честно говоря, я думаю, что вашей самой большой проблемой будет разработка ваших API для работы прекрасно как в мире REST, так и в RPC. Это два совершенно разных мира, и разработка «естественных» API-интерфейсов для удовлетворения обоих часто наносит ущерб одному или другому.

Технически говоря, если вы используете параметры, состоящие только из простых встроенных типов .NET (string, int, Guid и т. Д.), То все будет в порядке. Тем не менее, если вы хотите использовать свои собственные сложные типы, REST начнет распадаться на вас, если вы не проделаете большую работу, чтобы сопоставить запросы REST с этими типами, потому что они не предоставляются "из коробки". Таким образом, REST потенциально заставит вас изменить дизайн API, чтобы он был менее RPC'овским, что замечательно с точки зрения REST, но люди, которые обращаются к нему через RPC, могут задаться вопросом, что вы курили, когда смотрят на него.

Я должен добавить, что новый API WCF HTTP битов делает написание отображений для сложных типов намного проще, чем сегодня. Возможно, вы захотите поэкспериментировать с ними, если вы хотите продолжать заниматься этим, но они еще не RTM. Вы определенно по-прежнему столкнетесь с некоторыми проблемами несоответствия в стиле RPC и REST.